🚀 go-pugleaf

In article <964@hoptoad.uucp> tim@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.

> [discussion of sockets and socket based implementations removed]

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

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

> [discussions of mechanisms for protocol dependent system calls removed]

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.

> 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 have directed followups to net.dcom which appears to be the most suitable
group to continue this discussion.
-- 
Stephen J. Langdon                  ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]