ekrell@hector.UUCP (Eduardo Krell) (09/28/89)
In article <2509@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >I shall simply note that the streams mechanism is having stuff added to >it in S5R4 to support out-of-band data and to support TCP urgent data, >and note therefore that if the current BSD socket mechanism needs change >to support the ISO protocols, perhaps even including new system calls >(although, frankly, I would rather take e.g. Keith Sklower's word for >it that it's necessary than yours, since he's one of the people actually >*implementing* the ISO protocols on BSD), this cannot necessarily be >claimed as an advantage for S5 streams, since they required modification >as well.... 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. Conceptually, Streams is a clear winner. The implementation might not be perfect, but then I never argued that. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
guy@auspex.auspex.com (Guy Harris) (09/30/89)
> 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.)
chris@mimsy.UUCP (Chris Torek) (10/01/89)
In article <2515@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: [description of changes to socket interface, relayed from Keith Sklower] >It certainly didn't involve adding any new system calls. Well, no and yes. (heads up seanf :-) ) In fact several `new' syscalls were added, namely `accept', `bind', `connect', `sendmsg', and `recvmsg'. What? You say these already existed? That is where the `no' part comes in: The old versions of the system calls were retained for backwards compatibility; old binaries continue to run. The compatibility interface is slated to vanish in the next BSD (i.e., the one after the forthcoming release). I will admit that the basic design of Streams (in which data are passed back and forth between kernel modules using a uniform interface) is more elegant than the socket system call interface. However, the tasks put upon OSI or TCP streams are just as twisted as those put upon sockets, and the interface to those tasks is again just as twisted. The fact is that inter-network communication is ugly, and no one has, as yet, found the `right' way to make it clean (in the way that `devices and program-to-program streams [pipes] are files' did for Unix). All the problems of connection startup (rendezvous), bit and byte order and data incompatibility, and protocol goo show through, no matter whose implementation one uses. RPC libraries hide the goo well, but are language (and sometimes even compiler) specific, and have been inefficient (this concern is, as ever, vanishing under the tide of hardware improvement and compiler cleverness). Anyway, BSD may yet get streams, but only the kernel hackers will really notice. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris