Networking on UNIX - 3 approaches

[Steve Langdon]

In article <1019 at hoptoad.uucp> tim at hoptoad.UUCP (Tim Maroney) quotes my
reply to his original article on this topic.  He then writes:

> ...
> 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.

Tim and I will need to discuss this privately.  I have no desire to fight with
him on the net.  I respect his work, and I may have over-reacted to his
habit of expressing his views strongly.  I try (but may not always succeed )
to keep my criticisms muted, and react when I think someone is being unfair
or giving a one-sided view.

Returning to the technical aspects, in response to his description of the
difficulties in implementing SNA using sockets, I said:

< 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.

Tim's reply was:

> 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.

I think that one of the reasons Tim was upset at my reply is that he was
(in large part) attacking sockets (see below for evidence).  Defending sockets
was not relevant to the points that I was trying to make.  I still believe
that he is confusing the system interface mechanism issues with the problems
created by incompatible services.  Most of the Arpa protocols use a full-duplex
service model; SNA tends to use half-duplex, although it can support full-duplex
(I am talking about the SNA session level).

> >> [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?

I try to avoid long quotes - most people have the original available, and as
I said above, I was not agreeing with or disputing your comments about sockets.

I then defended the AT&T defined Transport Layer Interface (TLI).  Tim's
reply was:

> 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.

Once again I think this is an example of failing to distinguish between two
different things, in this case an interface and a protocol.  The TLI does
not define a protocol; it defines an interface that closely follows the
model provided by the abstract Transport Service definition.

Moving on to interfaces. I said:

< 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.

Tim replied:

> 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.

I think that my choice of words may have confused the issue.  The word
"exposed" was intended to mean "generally available" - in other words,
usable by a broad class of programs rather than other specialized software
in the layer above.  The above explanation notwithstanding, I find Tim's
claim that this means that "you have not provided the protocol" difficult
to understand.  Using SNA as an example, VTAM does not provide interfaces to
the protocols that implement the Virtual and Explict Routes.  Does this mean
that they have "not provided the protocol"?

The discussion then moves to "protocol independence". Tim said:

> It seems to me that protocols should be implemented in a freer way, with the
> impossibility of protocol independence recognized.  ...

I replied:

< 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

His response was:

> 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.

Once again a misunderstanding; I was not discussing sockets.  I was using
this point to illustrate that the Unix use of the file as an abstract interface
is quite similar to the OSI concept of a (protocol independent) service.

The discussion then moves to the basic streams interface.
I said:

< 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.

Tim replied:

> 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.

I am glad that we have finally found an issue about which we agree.
Once again I stress my interest in a constructive debate.  I am sorry my
last posting failed to avoid animosity, but I hope this one will not cause
further offense.
-- 
Steve Langdon  ...!{decwrl,sun,hplabs,ihnp4,cbosgd}!amdahl!sjl  +1 408 746 6970

[I speak for myself not others.]