The correct answer almost never includes task_for_pid(). ;-) So the system would be : - server add the new private port in its portset - server request a "no-senders" notification on the new private port 4) client get this new private port from the server (same method as 2 ) 5) client uses its private port to do RPC calls to the server Is this the idea? Thanks Stephane Letz _______________________________________________ darwin-development mailing list | darwin-development@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development Do not post admin requests to the list. They will be ignored. Besides, the task_for_pid() call you make above is just getting your own (client) task port. So, server_port should just be the same as what mach_task_self() returns. You didn't need to call task_for-pid() to get that. The second problem is that you are trying to use a send right (the client's reference to fServerPort) to create a send-once right (the one you try to make as part of the notification request). You simply cannot create a send-once right from a send right. Only the receive right can be used to make a send-once right. And that means that only the server itself can make this request. In trying to fix this, it is important to think about notifications in general. All Mach port notification messages are "port namespace relative" (only the name of the port is sent in the message). Within each task's port namespace, the mach_task_self() port likely has the same low-number name (because it is exposed during the pre-main() initialization of the process). So, nearly every one of the notification messages received by the server would look identical. Nothing would actually identify the client in any way known to the server. What you need is a reference, held by the server, that identifies each client. Then the server can request a notification about that reference. It is tempting to just have each client send the server their own task port to identify themselves. But that's a security issue if you don't trust the server whole-heartedly. You could just send a PID and have the server do the task_for_pid() itself. But then the client may just be spoofing the PID. In Panther 10.3.4 and above you could get a "trusted path" PID from the Mach message audit trailer to get around the spoofing. But this is all too kludgy. I f the server really does maintain state for each client independently, it should probably maintain a private connection with each such client. Just use the fServerPort (the one found in the bootstrap namespace) to have each client make a private connection to the server (the server creates a new, private, Mach port for the client and adds it to the portset that it waits on). The server can then request a "no-senders" notification on that private connection port to determine when the client goes away. --Jim I was thinking that doing the "task_get_bootstrap_port" and "bootstrap_look_up(fBootPort, "server", &fServerPort)" code on the client side (each client does that) was actually creating a new port for each client, but it seems this is not the case? All clients see the same "server" port allocated by the server? Is that correct? The thing is that doing this way the server was able to handle RPC call from all clients in the "mach_msg_server" call..... When you say "the server creates a new, private, Mach port for the client and adds it to the portset that it waits on", do you mean the server will create a additional port for each client and this additional port can be used also to make RPC calls from the client to the server? Then when you say "The server can then request a "no-senders" notification " do it means that the server has to use the "mach_port_request_notification" fucntion (not the client as I was doing..) 1) server first create the "server" port (bootstrap_register(fBootPort, "server", fServerPort)...) A kind of general entry point. 2) client get this port (task_get_bootstrap_port and bootstrap_look_up(fBootPort, "server", &fServerPort) to get this port to communicate with the server 3) client do a RPC call to register itself : - server receives this RPC call and create a new private port for the client 6) if client goes away, they the server receives a notification on the client private port and thus know which client went away