🚀 go-pugleaf

I have done a good deal of work with 4.2bsd networking - my first job at CMU
was to implement a socket interface for the UNIX SNA done at the Information
Technology Center.  During the course of this work, I came across some
serious deficiencies in the system.  It was almost impossible to fit a
half-duplex protocol like SNA into the model, and I expect that other
non-Internet protocols would probably suffer similar difficulties.  I was
forced to add new hooks to the protosw mechanism, for instance.  Imposing a
particular model of networking on all the protocols in the world seems to me
a highly questionable decision, since no one (ISORMites to the contrary) has
really formulated a general model of protocols.

This is particularly true since there is nothing in particular to recommend
the socket mechanism from a user interface perspective.  The only possible
recommendation would be protocol-independent software, and I think we all
know by now that this simply is not provided.  The meanings of the
"standard" primitives differ from protocol to protocol, and it is neccessary
to put in per-protocol cases in switch statements, which is definitely not
protocol independence.

This is even admitted by the way the Internet protocols are implemented.
Generally, a protocol implementer creates a protocol library which calls the
socket mechanism in order to provide protocol services in a straightforward
way.  This is no improvement over using special files and ioctl calls, and
in fact can be expected to incur additional context switching overhead as
multiple system calls are used to implement conceptually single protocol
operations.

The new Bell protocol-independent networking is even worse.  You can run
uucp and cu over Ethernet now.  I'd much rather have a poke in the eye with
a sharp stick.  Protocol independence is achieved at the expense of protocol
functionality, at least as I understood the USENIX papers.

It seems to me that protocols should be implemented in a freer way, with the
impossibility of protocol independence recognized.  An extended system call
mechanism seems the only good solution.  Each protocol would offer its own
system calls to user and kernel software.  This is essentially the way
sockets work now, albeit in a dishonest manner.  People who judge the
quality of a UNIX system by its number of system calls will no doubt scream,
but this is a simplistic and illusory criterion.  The socket mechanism
introduces even more complication; not only is it neccessary to know how the
protocol works, but one must find out (in what is usually rather sparse and
sketchy documentation, because it is not clear how to define a whole
protocol suite in a man page, unlike system calls) how the protocol maps
into the socket mechanism, and which functionality has been left out or
resigned to the ultimate admission of failure in sockets, the options
mechanism.  The use of new system calls for each protocol would actually
amount to a significant simplification of networking.

The implementation of such a mechanism is of course open to question.  I am
partial to using a special trap instruction, passing arguments on the stack
as usual, and passing a module id and routine selector in registers set
before invoking the trap, but there are a number of other alternatives.
Let's not get bogged down in questions of implementation at first; I would
like to see discussions of the merits and demerits of these three approaches
to networking on UNIX, however.
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)

Please stop using disclaimers.  I invented them because I had to.  Unless
you are in a similar situation of employer harassment, you have no need of
one, and they're darned annoying.