🚀 go-pugleaf

Actually, Rich is only partly correct.  On most systems the cost of
4.3BSD networking code (which is used by the netmsgserver) dominates all
other costs.  The netmsgserver has support for several protocols but the
standard one used at CMU (and by NeXT) is based on TCP connections.
There is code in the kernel for "short-circuiting" established Mach IPC
connections directly to the TCP code so when this option is used there
is no "intermediate" netmsgserver processing for each message.
Unfortunately the cost of IP/TCP code more than makes up the difference.
The last time I looked the cost of IP output was as high as 1600 VAX
instructions by itself.  We have experimented with various more high
performance protocols such as David Cheriton's VMTP.  A now somewhat
dated version of VMTP is an option in our system and the netmsgserver knows
how to use it.  That version of VMTP was never really stable in CMU's
complex network environment, though, so it has only been used for
experimentation.  It is likely that the most recent VMTP release will
be re-integrated and tested in the next few months.

Anyone interested in experimenting with the use of alternate protocols or
network driving code in Mach can do so relatively easily by modifying the
existing netmsgserver (which is already set up to handle 3 different
protocols) and the kernel's short-circuit code can be easily connected
to alternate network driver code.