Re: Using dead notification with mach ports
Re: Using dead notification with mach ports
- Subject: Re: Using dead notification with mach ports
- From: Stéphane Letz <email@hidden>
- Date: Fri, 10 Sep 2004 18:47:29 +0200
The correct answer almost never includes task_for_pid(). ;-)
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..)
So the system would be :
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
- 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
6) if client goes away, they the server receives a notification on the
client private port and thus know which client went away
Is this the idea?
Thanks
Stephane Letz
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.