Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!ns-mx!uunet!ukma!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!sample.eng.ohio-state.edu!purdue!news.cs.indiana.edu!mips!spool.mu.edu!snorkelwacker.mit.edu!hsdndev!bunny!cy01
From: cy01@gte.com (Che-Liang Yang)
Newsgroups: comp.os.mach
Subject: Do NetMsgServers really extend Mach IPC to network TRANSPARENTLY?
Message-ID: <11355@bunny.GTE.COM>
Date: 11 Jun 91 20:02:34 GMT
Organization: GTE Laboratories, Waltham MA
Lines: 84


Do MSD 2.6 NetMsgServers really extend Mach IPC to network TRANSPARENTLY?
I am not sure.  Here are three examples.


Example 1:

Suppose we have two Mach machines A and B.
Task A (in Machine A) creates a port, PORT A,
and gives the ownership right to Task B in Machine B.
According to the implementation of MSD 2.6 NetMsgServer:
in Kernel A, Task A has receive right (to Port A)
where NetMsgServer A has ownership right;
in Kernel B, Task B has ownership right
where NetMsgServer B has receive right.

Now suppose that Task B exits.
NetMsgServer A must transfer the ownership right back to Task A
while still retaining the send right.
According to the implementation, NetMsgServer A:
1. first msg_send itself a message with the send right to Port A,
2. port_deallocate Port A, (This will transfer the ownership right
   to Task A transparently.)
3. msg_receive the message with send right to Port A.

The problem is that the new port name obtained for Port A at step 3
is not the same as that in step 1 where the port record
for Port A in NetMsgServer A still uses the old name.
The consequence is that now no tasks on remote machines can
send messages to Port A (because NetMsgServer A will
relay the message to an invalid port.)
Further, if later Task A exits:
1. the logical name for Port A (checked in by Task A)
   will still hang in NetMsgServer A;
2. none of remote tasks with send rights to Port A will get notified.

I solved this problem by having NetMsgServer A
port_rename the new name to the old name.
Although this works for Mach 2.5 kernel,
this is not a safe solution because I assume that
the kernel will not immediately reuse the name assigned to a
port just deallocated.

So, my question is:
Under Mach 2.5 kernel, is there any safe way for a task
to transfer ownership right to another task
(which already has receive right) without sending a message
while still maintaining send right with the same name?


Example 2:

Task A creates a port, Port A,
and sends the receive/ownership right in a message, Msg A,
to Task B in Machine B.
Further, in Msg A, the "msg_type_deallocate" bit is on.

The problem is that when Task B receives Msg A (across the network),
the "msg_type_deallocate" bit was turned off by NetMsgServer B.
(NetMsgServer B has to turn it off when relaying Msg A
because it wants to retain the send right to Port A.)

Normally, this is not a big deal.
But, for applications that use MIG, this will cause the
server stub to reject request messages from remote machines.
In fact, an external pager in MSD 2.6 will never accept a
"memory_object_terminate" request from a remote kernel.


Example 3:

Task A creates Port A and Task B creates Port B.
Task A calls port_set_backup with primary = Port A
and backup = Port B.
Now, suppose that Machine A crashes.
I am sure that Task B will not receive the receive right to Port A
because when port_set_backup was called,
NetMsgServer A and then B were not informed by Kernel A.

This convinces me that the ownership abstraction is still useful
(for a task to back up a remote task) and should not be deleted.


C-L Yang