Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: Streams vs what? Message-ID: <2515@auspex.auspex.com> Date: 29 Sep 89 22:31:39 GMT Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 83 > But while the changes to Streams to support out-of-band and urgent data were > minimal, changing BSD sockets to support OSI or some other layered protocol > would involve much more work. And again, without a framework like > Streams, it would have to be done all over again for the next great > Protocol to be. Well, here's the word on how much work it actually took to put OSI under sockets, straight from the horse's mouth (well, actually, straight from Keith Sklower's keyboard) Changes in the Socket Interface to accomodate OSI protocols. The OSI transport protocols make use of some features that the 4.3BSD version of sockets didn't handle very grace- fully. However, by making rather modest changes, we have been able to incorporate an implementation of OSI TP with great success. The main change has been to the sendmsg()/recvmsg() system calls. Here we added three new entries to the msghdr structure: a returned value for flags, and a buffer and length for ancillary data. The motivation for a returned, in addition to requested, flags fields, is to unambigously convey ``end of record''. This also allows one to return expedited data, and mark it as such, without the expense of a separate sys- tem call enquiring (are we ``ATMARK''?), or the scheduling of an interrupt. The motivation for the ancillary data was to provide a separate place for user connect/confirm/disconnect data (which is not regarded as a part of the actual data stream), data stream type for XNS, ip options for IP, or any other protocol features that previously would have required look- ing at packet headers. Another common misconception is that sockets in and of themselves do not allow confirmation or rejection of connec- tion requests. Perhaps the accept() system call has been misnamed all along; it really should have been called dequeue_next_connect_request(). For the ISO case, accept() returns a file descriptor on which one can query for user connect data, and explicitly reject the connection request either by closing the file descriptor, or sending disconnect data. One can explicitly confirm the connection request by sending user confirm data, or implicitly confirm the connection by doing the normal operations of read and write. Another change to the socket layer has been to include a length field in all sockaddrs. Although we have been warned that a transport address may run up to 84 bytes (64 bytes of TSEL, 20 bytes of NSAP), it seems regretable and unnecessary to have fixed size address buffers for the worst case. A socket interface to Datakit would also make use of this feature. We have revised the kernel routing lookup software to deal with variable length addresses with hierarchical defaults in a uniform way. This doesn't seem to be a huge change; it may well be comparable in size to the changes to streams and to TLI (remember, in S5 at least, the equivalent to sockets isn't streams, it's streams plus TLI) to support out-of-band and urgent data. (The item about the routing lookup software doesn't apply, since S5 doesn't include general routing support code as 4.x BSD does, leaving the routing support up to the individual protocol implementations, although network-layer protocol implementors could agree to share a set of common code that they add to S5.) It certainly didn't involve adding any new system calls. Several of the changes generalize the sockets mechanism in ways that enhance its support of several different protocols, just as the changes to streams+TLI to support out-of-band data generalize streams (and, I hope, TLI) to enhance its support of several different protocols. I certainly don't see any indication that the next protocol along the line will require any more or less extensive changes to sockets than to streams+TLI. (If you leave TLI out, it may become trivially true of streams alone - but then, you can implement new protocols in BSD-flavored systems without putting them atop sockets, too.)