dmr@dutoit.UUCP (10/08/85)
Steven J. Langdon claimed that without multiplexing one couldn't do a proper kernel-resident version of TCP/IP in the V8 stream context. Here's how it's done. It is still true in our system that stream multiplexing does not occur, in the sense that every stream connection has (from the point of view of the formal data structures) exactly two ends, one at a user process, and the other at a device or another process. However, this has, in practice, not turned out to be a problem. Say you have a hardware device that hands you packets with a channel (or socket) number buried inside in some complicated format. The general scheme to handle the situation uses both a line discipline (stream filter module) and associated code that, to the system, looks like a stream device driver with several minor devices; these have entries in /dev. A watchdog process opens the underlying real device, and pushes the stream module. Arriving packets from the real device are passed to this module, where they are analyzed, and then given to the appropriate associated pseudo-device. Likewise, messages written on the pseudo-device are shunted over to the line discipline, where they are encoded appropriately and sent to the real device. This is where the multiplexing-demultiplexing occurs; formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules. For example, IP works this way: The IP line discipline looks at the type field of data arriving from the device, and determines whether the packet is TCP or UDP or ARP or whatever, and shunts it off to the stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers are. TCP, of course, is multiplexed as well. So there is a TCP line discipline, and a bunch of TCP devices; a watchdog process opens /dev/ip6, and pushes the TCP line discipline; then the TCP packets it gets are parcelled out to the appropriate /dev/tcpXX device. Each TCP device looks like the end of a stream, and may, of course, have other modules (e.g. tty processor) inserted in this stream. UDP sits on top of IP in the same way. This example is complicated, because (TCP,UDP)/IP is. However, it works well. In particular, the underlying real device can be either an ethernet or our own Datakit network; the software doesn't care. For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to. A further generalization (that we haven't made) is in principle easy: there can be protocol suites other than IP on an Ethernet cable. So there could be another layer to separate IP from XNS from Chaosnet, etc. Dennis Ritchie
sjl@amdahl.UUCP (Steve Langdon) (10/10/85)
In article <2060@dutoit.UUCP> Dennis Ritchie replied to my article
<2084@amdahl.UUCP> by politely explaining that V8 streams can and do
support TCP/IP in the kernel. His article did a much better job than I
did of making my main point - streams are capable of supporting
connectionless (i.e. datagram) communication as well as connection
oriented communication.
My statements about multiplexing were based on the third from last
paragraph in Dennis's BLTJ paper describing streams (page 1909).
Copyright prevents me from quoting this paragraph, but it gives the clear
impression that multiplexing via pseudo-devices was not present when the
paper was written. The description Dennis gave of how multiplexing is
done in the V8 kernel is a useful addition to the publicly available
material describing streams.
--
Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl
[ The article above is not an official statement from any organization
in the known universe. ]