Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
- Subject: Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
- From: Mail Delivery Subsystem <email@hidden>
- Date: Mon, 13 Sep 2004 07:31:42 -0700 (PDT)
- Resent-date: Mon, 13 Sep 2004 16:38:06 +0200
- Resent-from: Stéphane Letz <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
De: Stéphane Letz <email@hidden>
Date: 13 septembre 2004 16:35:33 GMT+02:00
À: Jim Magee <email@hidden>
Cc: email@hidden
Objet: Rép : Using dead notification with mach ports
Sorry, I sent that early by mistake....
Anyway, one of the 2 or 3 primary advantages of Mach IPC over other forms is the flexibility in passing other port rights in messages. Since it appears you are using MIG, you simply have to declare an "out" parameter (or two, if you count sending the semaphore as well) of type mach_port_t. That will arrange to have send rights transfered to the client (copied, to be explicit). But for the no-senders notification to fire, the server can't hold its own send right to that port (and you have given the server a send right with the mach_port_insert_right() call above). Instead, it must "move" the send right it created to the client. You can do this in one of two ways:
You can declare the "out" parameter as type "mach_port_move_send_t" in the MIG definition
or
You could declare it of type "mach_port_make_send_t" and skip the call to mach_port_insert_right() altogether
Here's an example MIG definition that assumes the latter approach:
routine StephaneConnectToServer
(
serverPort : mach_port_t;
connectFlags : integer_t;
out semaphorePort: semaphore_t;
out connectionPort: mach_port_make_send_t
);
Hope that helps,
--Jim
Thanks a lot!
I re-read the server_writer documentation and things start to become clear. But I also need to be able to do MIG generated RPC form server to client (since the server needs to notify the clients). Thus 2 "private" ports seems to be needed between the server and client for each new client.
Here is what I have understood the way it should be done :
On the server side :
--------------------------
- register the "server port" in the global name space with (mach_port_allocate, mach_port_insert_right and bootstrap_register)
- allocate a "notify" port
- allocate a "port-set"
- move the "server port" and "notify" port in "port-set"
- use a custom MIG server routine that listen on the "port-set and distinguish between the "server port" and "notify" port:
- messages coming from "server port" (or private client ports) are handled using the "server_routine" to call MIG generated RPC
- messages coming from "notify port" are handle using the "notify_server" special routine that will redirect on the appropriate "do_mac_notify_dead_name" and other notification routines
On the client side :
--------------------------
- define a MIG RPC routine like :
StephaneConnectToServer ( serverPort : mach_port_t; connectFlags : integer_t;
clientPort : mach_port_t;
out semaphorePort: semaphore_t;
out serverPort: mach_port_make_send_t );
- to register a new client :
- allocate a port with receive rights for MIG RPC server==>client communication
- call StephaneConnectToServer(.... clientPort ....)
On the server side :
--------------------------
- Handling of "StephaneConnectToServer" :
- keeps the "clientPort" port
- allocate a new mach private port with receive rights for MIG RPC client==>server communication
- register a notification on this private port with "mach_port_request_notification"
- move the private port in the "port-set" to be able to listen to future request of the new client
Is this description correct?
It is still not completely clear which of the "do_mach_notify_no_senders" or "do_mac_notify_dead_name" I will have to use.
Another question : notification will allow the server to know when clients disappear abnormally. What happens in the contrary case? Can clients be notified if the server disappear?
Thanks
Stephane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden