Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards,net.lan Subject: Re: STREAMS query Message-ID: <2864@sun.uucp> Date: Wed, 9-Oct-85 05:13:59 EDT Article-I.D.: sun.2864 Posted: Wed Oct 9 05:13:59 1985 Date-Received: Sat, 12-Oct-85 17:40:49 EDT References: <471@enmasse.UUCP> <1699@brl-tgr.ARPA> <449@cheviot.uucp> <1542@hammer.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 70 Xref: watmath net.unix-wizards:15180 net.lan:1072 > 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