Can multiple webservices be called with one connection simultaneously using NSURLConnection?
Or do I have to create a connection for each call?
No, you have to create a NSURLConnection object for each request. Once the NSURLConnection object is finished, it cannot be reused - as opposed to the NSURLRequest.
Related
I try to find some fast algorithm of interprocess communication.
One of I need is an ability to send one command to multiple application instances at the same time. I had tried to find out for a day if I am able to start many instances of the same app (local-rpc-server-app) and call RPC from one client. I use ncalrpc protocol for this purpose.
I just want to start several instances of server and one instance if client, and then call the same RPC func one time on a client to evaluate this RPC func on every running server.
Yes, you can either use multiple client threads (each making a separate server call) or modify the .acf and mark the call with the [async] attribute. If you go the latter route you can then make multiple calls on a single client thread. Note that asynchronous RPC is a fair bit more complicated than synchronous RPC due to needing to deal with call completions.
Making calls to multiple server instances (even local instances) is also made more complicated by the fact that you will have to somehow discover those endpoints, and the RPC namespace functions (RpcNs*) are no longer available as of Windows Vista.
I am working on an application where i have separated out two different XPC services from the main application. I want a XPC service to communicate with other XPC service which will do some processing and will return the data back to first service and that first service will do its own processing and then will give data back to the main application. I even tried this but communicating between the services give error that "could not communicate with helper application".
My question is that either this is possible or not? If yes that what is required?
Any help would be appreciated.
Yes, this is possible, but not at all obvious. I asked questions about this exact thing on and off for a year before an obscure hint from an Apple engineer led me to stumble across the answer.
The trick is that you need to transfer the NSXPCListenerEndpoint of one process to another process. That second process can then use that endpoint object to create a direct connection with the first process. The catch is that, while NSXPCListenerEndpoint is NSCoding compliant, it can only be encoded through an existing XPC connection, which makes this problem sound like a catch-22 (you can't transfer the endpoint until you've created a connection, and you can't create a connection until you have the endpoint).
The solution ("trick") is you need an intermediating process (let's call it "cornerstone") that already has an XPC connections that can exchange endpoints between the other two processes.
In my application I ended up creating a daemon process which acts as my cornerstone, but I think you could do it directly in your application. Here's what you need to do:
Create an application with two XPC services, "A" and "B"
In "A" get the listener object for the process: either get the service listener created automatically (listener = NSXPCListener.serviceListener) or create a dedicated, anonymous, listener for the second process (using listener = NSXPCListener.anonymousListener).
Get the endpoint of the listener (listener.endpoint)
The application should ask "A" for its endpoint.
The application can then launch "B" and, using XPC again, pass the endpoint it got from "A" to "B".
"B" can now use the endpoint object it obtained from "A" (via the application) to create a direct connection to "A" using [[NSXPCConnection alloc] initWithListenerEndpoint:aEndpoint]].
So I have found that two processes are inevitably going to be unable to communicate to the same XPCService. That is because if you try to launch an XPCService, it will be a unique process to the launcher. And as far as I can tell, you can only communicate with an XPCService that your process launched.
So I believe your second XPCService will be unable to "launch" the first XPCService, and therefore will be unable to communicate with it.
The best you can probably do is have your second XPCService communicate back to your main application process, which then communicates to the first XPCService.
You could do something like:
[[self.firstXPCConnection remoteObjectProxy] getSomeString:^(NSString *myString) {
[[self.secondXPCConnection remoteObjectProxy] passSomeString:myString];
}];
Though disclaimer, I haven't tried this. But the best I can help you with the knowledge I have
What do you gain by returning Task types from SignalR hub methods, and what are the use cases for doing so?
If you are doing asynchronous operations inside of a Hub method such as DB queries or web requests, it can be more efficient to use the async/await pattern instead of blocking. SignalR will wait for the Tasks returned from Hub methods to complete before sending the unwrapped result back to the calling client. SignalR will also make sure not dispose your Hub until the returned Task completes.
If you are not yet using .NET 4.5, you can use Task.ContinueWith or create your own Tasks using a TaskCompletionSource if you are not working with a Task returning library.
My design is in a spot of bother, mainly because a requirement of it is to be able to support cancellation of NSURLConnections that are in progress.
I've heard plenty of people say that you cannot send the cancel message to NSURLConnections objects that are running in synchronous mode, but is this solely because of the logistics of it? For example, if an NSURLConnection is loading synchronously, then the cancel message sent on the same thread wouldn't be received by the connection object until after the connection has finished anyway.
What I'm hoping is that it is possible to send a SYNCHRONOUS NSURLConnection object the cancel message from another thread.
Does anyone know if this is possible or have tried it before?
Regards,
Nick
Answering my own question:
No, it isn't! Quite simply because the class method to which you start a synchronous NSURLConnection doesn't return a connection object (upon which you would call the cancel method) - it returns an NSData object instead!
Is there any way to make non-blocking SOAP requests within EventMachine?
I'm creating a ruby application which interacts with the google adwords api (which is SOAP based), using the adwords4r gem. The application uses EM to receive messages over a stomp connection, and then processes those messages by making SOAP calls to the adwords api. Obviously I need those calls to be non-blocking, since the processing will be within the reactor thread. One option would be to use EM.defer, but I'd rather not have the overhead of a bunch of threads in a threadpool.
HandSoap can use EventMachine.
After earning a tumbleweed badge with this question I ended up asking on the #eventmachine IRC. Apparently there is no eventmachine-friendly options for making SOAP calls, besides using EM.defer