Networking on UNIX - 3 approaches

[tim at hoptoad.UUCP]

In article <3535 at amdahl.UUCP> sjl at amdahl.UUCP (Steve Langdon) writes:
>In article <964 at hoptoad.uucp> tim at hoptoad.uucp (Tim Maroney) writes:
>
>> 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.
>
>As a card carrying ISORMite I cannot help but take issue with Tim's statements.
>His posting shows a basic misunderstanding about the difference between the
>protocol used in a layer and the service provided by the layer.  The example
>he gives is clearly based on different services (ie. half-duplex vs. duplex)
>rather than protocol differences.  I would be the last person to claim that
>the OSI model, service definitions, or protocols are perfect.
>However, one of the best things about OSI is the idea of clearly dividing an
>abstract service from the protocol(s) which implement it.

In this and another recent message (on net.micro.mac), Steve shows his
inability to make a point without casting aspersions on the intelligence or
character of the person he disagrees with.  If he wishes me to take his
messages seriously, I hope this will change.

In any case, the above paragraph says nothing substantial, and fails to
answer my statement concerning the inapplicability of the socket mechanism
to SNA.  Three of us, two of whom were seasoned SNA hackers, labored for a
few months and we were unable to fit SNA into the model without postulating
a simulated full-duplex connection formed of two half-duplex connections
created by agreeing clients on both ends.  All the vague talk in the world
about protocols versus services does not answer the inapplicability of the
socket mechanism to providing SNA services to application software.

>> [discussion of sockets and socket based implementations removed]

Why?  This omitted section contained most of the substance of my message,
and almost the entirety of my demonstration of the poorness of the socket
model.  Why not omit my whole message?

>> 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.
>
>I have not read the USENIX papers, but I have had many discussions with
>Gill McGrath and others at Summit who were responsible for the new
>Transport Layer Interface (TLI).  I think they did an excellent job of
>designing an interface which provides the Transport Service without exposing
>protocol implementation details.

My objection was based on a misconception that the transport layer interface
was the entirety of the system.  The stream support should be able to
provide all necessary protocol functionality.  This doesn't change the fact
that I think the transport layer interface is very bad.  It defines new
protocols, which are the last thing we need, and does so informally, which
we should all have been scared away from by uucp.  Finally, it is limited to
SV.3 to SV.3 connection.

>I should add that my praise for this
>example does not mean that it is necessary, or desirable, to view all OSI
>layer interfaces as software module interfaces.  Efficiency will often
>require layers to be implemented without an exposed "service" interface.

I could not possibly disagree with you more.  If you have not provided a
software interface for a protocol except one usable by higher-level
protocols in the same project, then you have not provided the protocol.  If
a protocol is designed in such a way that no efficient software interface
can be provided, then the protocol has been very poorly designed.

>> It seems to me that protocols should be implemented in a freer way, with the
>> impossibility of protocol independence recognized.  ...
>
>If you follow this argument to its logical conclusion you would also eliminate
>stdio and many of the IO abstractions which are central to the success of Unix.

Not at all.  There is a great difference between a good model and a bad
model.  The UNIX file descriptor mechanism is a good model for files and
devices of most kinds.  The services of nearly all devices can be fit rather
cleanly into the model.  My point was that just this quality is lacking in
the socket mechanism.  A bad common model, which sockets are, is more
restrictive and awkward than no common model at all.

>What is your objection to the mechanism provided by System V Rel 3 streams?
>It allows user programs to pass protocol specific information to kernal
>resident protocol stream modules or drivers.  Use of the TLI is encouraged
>where appropriate, but the general case is still covered.

This was certainly not stressed in the presentation.  I have just reviewed
the paper and this appears to be correct.  As we all know, streams are a
classic elegant Ritchie solution.  They also fit my criterion for an extended
system call mechanism (as do normal special file ioctls).  I believe I was
misled by the enthusiams for the transport layer interface at the expense of
discussion of the stream interface, but in any case, I withdraw my objection
to SV.3 networking support.  It does appear to be sufficiently
non-restrictive, and also to allow modular protocol development.

>> 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.
>
>I may have seemed rather harsh on Tim, but that was not my intent.  In fact,
>he presented his views in enough detail so that a reasoned response was
>possible.  Unfortunately, many others who voice opinions do not offer enough
>information to allow a specific reply.

I'm glad to know a reasoned response was possible; I eagerly await it :-).
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim at lll-crg (arpa)

Bibliolatry is my bizarreness.