STREAMS query

[Guy Harris]

> Sockets are very much like streams.

Actually, sockets are a descriptor-level interface to a networking
implementation, and streams are a mechanism for connecting various
device drivers and protocol layers.  One could, presumably, replace the
current 4.2BSD protocol-protocol and protocol-"interface" mechanism with a
stream mechanism and leave the current networking system calls in place.

The papers on streams are rather silent on how you do anything other than
reading from or writing to a stream.  One might infer that you open
"/dev/ec0", push an IP stream processing module on top of it, and a TCP or
UDP stream processing module on top of that, but:

	1) this doesn't win if you have multiple network interfaces,
	   are trying to connect to a host not on a network that
	   you're on, and want the route to that host to be determined
	   dynamically on an IP-datagram-by-IP-datagram basis (I suppose
	   you could have it tear down all stream connections and rebuild
	   them if the route changes, but that seems messy).

	2) this also is a mess if somebody else is using the same
	   Ethernet interface - if the Ethernet driver is talking to
	   two higher-level protocol modules, how does it know which
	   one to route which packets to?  (We assume here that there
	   is one instance of the IP stream processing module per TCP
	   or UDP stream.)

It seems fairly clear that if TCP/UDP/IP or a similar protocol suite is
implemented using the streams mechanism, it isn't done this way.
Unfortunately, I've seen nothing to indicate how it *is* done.  Presumably,
instantiations of stream processing modules can have more than one upstream
and one downstream module.

In a system with TCP/UDP/IP, for instance, there would be one instantiation
of the IP module.  It would have multiple network interface drivers
downstream of it, and packets would get put on the queues of the downstream
modules based on the route to the host the packet is intended for.  Upstream
of the IP module, there might be one instantiation of the TCP module and one
instantiation of the UDP module, and the IP module would put packets on the
queue of one or the other based on the protocol type; alternatively, there
might be one instantiation of the TCP or UDP module per active TCP or UDP
file table entry.

> The main advantages of streams over sockets are:
> ...
> 	5.  less wired in knowledge of TCP/IP - potential to support
> 	    other protocols easier (yeah I know that 4.2 tried to solve
> 	    this problem, but they got a few things wrong here)

Presumably, 4.3 fixed this to support XNS.  In a streams-based mechanism as
described above, the routing code used by the IP module could as full of IP
dependencies as the 4.2 routing code.

> Advantages the other way include:
> 
> 	1.  sockets that are embedded in the file system name space
> 	    (but you can't just open(2) them though).
> 
> 	2.  the ability to pass file descriptors through unix domain
> 	    sockets (this *may* make it into AT&T).

The paper on "Interprocess Communication in the Eighth Edition Unix System",
by D. L. Presotto and DMR, given at the Portland USENIX describes mechanisms
to provide both these capabilities - "mounted streams" to attach file system
name space names to streams (and you *can* open them), and "ioctl"
operations to pass file descriptors over streams (although the paper is
silent on what it means to pass a file descriptor to a TOPS-20 system on the
other end of a TCP connection).

	Guy Harris