alternative: port server?

[Marcus Brinkmann]

Hi,

so far we have tried to encourage a design that allows direct communication
from any user to any server.  I think we have found ways to make that work.

However, another design is possible, and we shouldn't commit the sin of not
taking it into consideration before making a decision.

The other concept is to have a server managing ports, just like Mach manages
ports for us.  However, I wouldn't want to keep the whole port concept of
Mach.  The communication would still be synchronous, for example, not
buffered. (If objects are managed within the portserver or within each
server is also a valid question, raised below in conjunction with resource
management).

The portserver would keep track of moved object handles.  It could also keep
track of objects themselves (so moving receive rights would be possible).
It can manage automatic deallocation and notifications.  As the default port
server would be trusted, it could use an efficient protocol with the task
server to avoid races with PID usage.  This would basically eliminate all
the problems we had in defining good protocols to move handles avoid thread
id reusage.

L4 does support such a model very well.  You can restrict a thread so that
it can only send local messages directly.  Messages to other address spaces
have to go through a redirector, which would be the portserver.  The
redirector can only be set by the privileged space control call.  The
portserver can efficiently redirect simple messages to the destination
server, while other messages will have a certain overhead (if objects need
to be moved).  L4 makes the actual sender available to the receiving thread. 
The server can then send the reply directly to the sender, avoiding the port
server in the reply (only if the server must use the portserver to move a
send right to the user, for example, see below).  The overhead is thus one
context switch to the portserver, plus whatever fix up is needed to
manipulate port handles in transit.

Now, that is the bright side of this.  The dark side is not without
concerns.  First, the portserver allocates resources on the servers and
clients behalf.  Also, if the server sends back handles, it suddenly needs
the port servers cooperation.  Thus, if we would clone the mach model, it
would be required that the user sets up a reply port in which it receives
the reply from the server.  If one is not careful, the overhead can easily
go up to 8 context switches or more instead 3 for a roundtrip.
Also, it would be better if the servers would provide the user and object
data to the portserver via mapped memory (to better track general resource
usage and eliminate the need for server<->portserver communication). 
However, in this case, the portserver needs to synchronize access to the
data with the server and I am not sure what a good protocol for this would
be (robustness and performance are two important criteria here).  It might
end up to be more hassle to do it this (proper) way than to just use the
direct communication proposed so far.

The advantage is that if you consistently use redirectors in the system for
inter-address-space communication, it might be somewhat easier to write
robust software, because you can be sure that no thread can send arbitrary
messages to any other thread.  OTOH, this is only relevant if you have
threads that wait for any thread (not just any local thread) and wouldn't
use the normal Hurd library for servers (which of course will check that the
sender is allowed to send the message in question).

I think this scheme should only be considered if it is clear that the
portserver can use mapped memory from servers instead providing the
resources itself.  Also, it is only worth the cost if send rights are moved
frequently, because it punishes each message with an overhead, while the
currently suggested scheme allows maximum performance to simple messages
while right moving messages are punished.  io_read is an example which is
performance critical but doesn't require transfering rights.  Things like
exec_exec are different, but the cost of setting up a new task is high
anyway.  So it's not clear that a constant small overhead is better here
than an infrequent higher one.

The other argument for the currently proposed solution is that it is
decentral and doesn't require a central, privileged system component.  This
makes it more hurdish and elegant.  So I think that even if this solution
turns out to be a bit more complex than the portserver based one (however, I
am not even sure that this is the case), it is worth it as long as it is
equally robust.

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/