I have two independent applications (cocoa), one main, the other slave.
The main application application is embedding a XPCService, which is correctly launched when the application is opened. No problems so far for connecting and exchanging data with that service (I also see this XPCService in the Activity Monitor).
But I want the other slave application to connect and send data to that XPC Service (and then to the main first application) after it has been launched by the main one.
Using NSXPCConnection (with initWithMachServiceName), and the correct Service bundle identifier doesn't work: no NewConnection delegate is called so the slave application never reach the service.
What am I missing ? Is what I want is possible with NSXPCConnection ?
Is it because I need the XPCService (within plist) to be shared in some way ? In that case what should I do ?
I can't find any information about this sort connection !
Thanks a lot for your help !
"I have two independent applications "
As stated in Apple's Documentation for XPC:
an XPC service is private, and is available only to the main application that contains it.
For security, an application that contains an XPC helper app gets signed to ensure that only the main application is allowed to call up on its helper.
However, it should be noted that the documentation also states
A connection is a virtual endpoint; it is independent of whether an actual instance of the service binary is running. The service binary is launched on demand.
A connection can also be sent as a piece of data in an XPC message. Thus, you can pass a connection through XPC to allow one service to communicate with another service (for example).
Though I've not seen this in practice, it does imply that you may be able to initiate the connection from the main application to the XPC helper and send this connection to your 'slave' app.
Related
I would like to make a IPC between two processes using Windows RPC. Please explain me like I am five how my application should achieve good security. I want to use ncalrpc protocol (processes on the same computer). More exactly:
How my client application knows that the server is trusty?
How my server know if the callee is the trusted one?
What options do I have? I didn't get RpcBindingSetAuthInfo function.
Thanks
For a local connection having the client authenticate the server is fairly hard (for example confirming that some other service did not start in place of the desired program) but having the server identify the client is not, call RpcBindingInqAuthClient and use the username to determine what action to take, or just use RpcImpersonateClient if you can rely on existing secured objects. Most of the RPC security apparatus is for remote connections rather than ncalrpc.
I have two different service fabric applications. Both are stateless web api models. I do have a situation that from service 1 inside application 1, I need to invoke service 2 which is part of application 2. I am deploying both applications in the same cluster. Can someone advise the best practice here. What could be best way to communicate. Please provide some sample as well.
Fabric Transport (aka Service Remoting) is the sdk built-in communication model. Compared to communication over HTTP or WCF it does a little more, especially on the client side of the communication.
When it comes to communicating with Service Fabric services (or really, any distributed systems service) your communication should take into account that the connection could be fail to established on an initial try, or be interrupted mid communication and that you really shouldn't build your solution to expect it to always work flawlessly. The reason for this is in the nature of how Service Fabric at any time can decide to move primaries from a node to another node, the nodes themselves can go down and the services can crash. Nothing strange about he great thing with Service Fabric is that it does a lot of the heavy lifting for you when it comes to maintaining your services and nodes over time.
So, in terms of communication this means that a client needs to be able to do three things (for it to truly work in a distributed environment);
resolve the address to the service (figure out which node it is on, which port it is listening on, which partition id and replica to target and so on)
connect to the service, package and send requests and then recieve and unpack responses
retry the resolve and connect if the communication fails
Fabric Transport does all this when you are using the Service Remoting clients (like ServiceProxy) and service side listeners.
Thats the good part with Fabric Transport, you get all that out of the box and most of the time you don't have to change the default setup either. The bad part is that it only works for communication inside the cluster, i.e. you cannot communicate from the outside to a service running in the cluster using Fabric Transport. For that you need HTTP or WCF.
HTTP(s) and WCF (over HTTP(s)) communication allow you to build your own clients and handle the communication yourself. There are a number of samples on how you can do the resolve, connect and retry for HTTP clients, this one for instance
According to Microsoft there are three built-in communication options. It's up to you to decide which one works best for you. I'm personally using service remoting which is easy to quickly set up. It also allows you to exception handling in your client service.
I need detect application name, that communicate from internet.
Is it possible detecting application from catched communication?
If you're actually asking about Fiddler (which runs locally on your PC), the originating Process Name is shown in a column and is available via the LocalProcess property of the Session.
We have a legacy vb6 automation application that communicate over a sockets on need basis.
But opening and establishing connection (only when required) to the remote port taking more time frequently.
So,i am planning to write other application (say a socket server) that opens the required sockets and keep the connections alive.This application will write connected socket handle values to a file or database.
Is it possible in vb6 to create a socket object using socket handle from the already opened socket that was owned by other process (socket server application in this case)?
This is exactly the type of situation that WSADuplicateSocket() is intended for.
Your "server" can create a socket and use WSADuplicateSocket() to fill a WSAPROTOCOL_INFO record that describes the socket. The "server" can then expose the WSAPROTOCOL_INFO to your VB app using any IPC mechanism you want. The VB app can pass the WSAPROTOCOL_INFO to WSASocket() to access the socket and use it as needed.
No, Windows sockets cannot be shared cross-process, not even through handle inheritance (this is because although it is usually a handle, an LSP might return something that is not a handle and thus not inherited). You should make one process open and maintain the connection and the others talk to that process to communicate with the server.
I am doing a simple bonjour broadcast using NSNetServices. Everything is working great when I start and stop the bonjour sharing at application launch/quit. However if I turn off bonjour using the stop method call, my app still appears to be broadcasting a dead service even after the netServiceDidStop: delegate message gets called, which prevents restarting of the service until after a relaunch of the app. Apple's documentation makes it look very straightforward, just publish or stop as needed... Am I missing something?
It seems that sometimes services are shown even when they are no longer available.
From Apple documentation:
Because failing to show a valid service is a bigger problem for the user than showing a stale service, Bonjour deliberately errs on the side of assuming that a service is still available.
.
.
although Bonjour generally discovers new services within a few
seconds, if a service goes away, the disappearance of the service may
not be discovered until your app tries to connect to it and gets no
response.
You should not assume that just because the Bonjour APIs report a
discovered service, the service is guaranteed to be available when the
software tries to access it.
Connecting to and Monitoring Network Services: When resolving fails