🚀 go-pugleaf

As indicated in several earlier posts, the major cost of the current
implementation of Mach IPC (RPC) appears to be the low-level transport
protocol used. The "standard" Mach netmsgserver uses TCP/IP over UNIX
sockets. TCP was selected because it provided the best combination of
performance and robustness on large, complicated networks. Note that
this issue of robustness is particularly important at CMU. There are
over 1700 machines on the CMU network, with almost 800 in the School
of Computer Science alone, of which more than 500 are running Mach. On
an average day, few of these machines might be actively engaged in
doing Mach network RPC's, but the chances that two communicating
machines are on the same physical cable are quite low. In addition, we
have to contend with a lot of background traffic, and non-negligible
packet losses.

We have been thinking about using different transport protocols in
different situations for quite a while, but never got around to it.
For the future, we are investigating the use of the x-kernel "virtual
protocols" mechanism to fulfill this function.

Our plans for the x-kernel are not finalized, but current prototypes
assume a system running at user-level in a Mach task. However, we are
also working on user-level device drivers, which should take care of
the argument against paying a protection boundary crossing for network
access. 

Finally, since someone asked, there is no "serious" netmsgserver
distributed with Mach 3.0. I have put together an adaptation of the
netmsgserver from the 2.5 system to use TCP sockets emulated in the
UNIX server, but this is clearly not an interesting long-term
solution. Again, in the longer term, we hope to use x-kernel
technology instead.


======================================================================
Daniel Julin                                            dpj@cs.cmu.edu
School of Computer Science
Carnegie Mellon University, Pittsburgh, PA 15213
======================================================================