🚀 go-pugleaf

In article <1991Jun1.234148.921@eng.ufl.edu> bcs@frenulum.eng.ufl.edu (Bradley C. Spatz) writes:
> I have two questions related to Mach RPC between two (or more) physically
> separated hosts:
>
> 1) What transport protocols are used for RPCs?
> 2) How is data representation handled (is there an XDR-like
> standard for Mach RPC)?
>
> I think both of these functions fall under the aupices of the NetMsgServer that
> extends IPC across the network.  I thought I had all the docs for 2.5, but
> I don't see anything concerning the NetMsgServer, beyond the netname services.
>
> Is there a document that explicitly describes the NetMsgServer (and not the doc
> on network server design)?

The "Network Server Design Document" in the standard Mach doc
directory is the primary reference for people who are modifying or
maintaining the netmsgserver. It corresponds to the sources
distributed with the 2.5 release. Beyond that, you'll have to "use the
force and read the code"!  I have also written a protocol description
a long time ago; it is in /usr/dpj/public/protocol.ps on
wb1.cs.cmu.edu. This document is still theoretically only a draft, but
I haven't had time to work on it for years, so I guess it's as good as
it will get...

As for your specific questions:

1) The transport protocol to use is specified in config.h when
compiling the netmsgserver. The default as distributed (and the only
one seriously used to my knowledge) is TCP over UNIX sockets, with
special care to try to optimize performance by caching open
connections, being clever with TCP buffering, exploiting delayed
ACK's, etc. This will almost certainly change drastically with future
revisions of the netmsgserver for Mach 3.0, but I don't know when that
will happen.

2) The data in messages is naturally described as part of the Mach
message format (msg_type_t and co.). For network communication, the
netmsgserver uses the "receiver-makes-right" strategy. The sender
sends the data as-is, accompanied by a header that indicates the byte
ordering and other interesting characteristics. The receiver performs
all conversions if and when needed.


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