Re: DO over unnamed sockets
Re: DO over unnamed sockets
- Subject: Re: DO over unnamed sockets
- From: Ken Thomases <email@hidden>
- Date: Sat, 23 Oct 2010 10:00:27 -0500
On Oct 23, 2010, at 6:00 AM, Dave Keck wrote:
> Can DO work over unnamed sockets?
It appears not. I wasn't able to find a way to make your code work, either.
My past experience and the Distributed Objects Programming Guide both suggest that NSConnection expects to work more like the case with "named" sockets. The server's connection, denoted as a circled 's' in the guide, is a connection point, like a socket that's had bind() and listen() called on it. When the receive port is "readable", NSConnection does the equivalent of an accept() on it, receives a new socket file descriptor, and creates a new child NSConnection to handle the connection from the client.
The client, for its part, is attempting a connect() to the server. I think this is what's giving the error and the framework is merely interpreting it as a timeout.
You can verify this by breaking on connect() or using dtruss or the like. It's actually getting ENOENT. It appears be using getsockname() on the send port's socket to figure out where to connect, and that's giving a sockaddr_un with an empty sun_path.
You can achieve something like what you want using NSMachPorts (or just plain NSPorts), but only within a single process. That's because of NSConnection's documented behavior that two instances initialized with the same ports but reversed in role are automatically considered connected to each other. So, you create two ports with [NSPort port] and the server creates its connection with them in one order and the client creates its with them in the other order. The client can obtain the root proxy just fine in this case.
This breaks down with two processes, because the port objects can't be correlated between them. The two processes don't share the same objects, and the NSConnection class in each doesn't have visibility over the instances in both in order to realize that one is created with the same ports as another but swapped in role.
I don't think that the raw Mach port rights are inherited through a fork-exec, unfortunately. If they were, I think you could create a connection with them successfully. That is, I don't think it would have the same problem plaguing the sockets where one connection is treated as a connection point rather than an actual communication channel. (That's because Mach messaging doesn't need to create new Mach ports for every client. Each received message comes with a reply port, so the server can keep things straight with just the one Mach receive port.)
But, if I'm right that you can't inherit the Mach port rights, then you'd need to register the server with a name server, which is what you're trying to avoid.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden