Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sockets vs streams. An attempt to answer the original question Message-ID: Date: 2 Sep 90 18:45:24 GMT References: <9008242107.AA19843@ucbvax.Berkeley.EDU> <1990Aug27.111656.1@amazon.llnl.gov> <1990Aug28.162400.17811@zoo.toronto.edu> <38584@ucbvax.BERKELEY.EDU> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 87 In-reply-to: sklower@ernie.Berkeley.EDU's message of 31 Aug 90 19:48:37 GMT On 31 Aug 90 19:48:37 GMT, sklower@ernie.Berkeley.EDU (Keith Sklower) said: sklower> In article <1990Aug28.162400.17811@zoo.toronto.edu> sklower> henry@zoo.toronto.edu (Henry Spencer) writes: spencer> The way to do i/o on Dennis's streams was with "read" and "write". spencer> Network i/o, in general, looked *exactly* like local device i/o. Note that with the most recent developments of UNIX (FSS) read() and write() no longer mean much, except 'move data from/to the kernel'; they have become just a way to add new system calls, using a file like style of interface. The semantics of write() and read() have become very very loose. What does read/write mean on /dev/proc? Something highly non obvious. spencer> This is the way it should be, unlike what both Berkeley and spencer> AT&T have done (both have reluctantly conceded that most people spencer> want to use "read" and "write" and have made that work, but spencer> their hearts were clearly elsewhere). And for good reason! read() and write() on file descriptors is not the most amusing interface. It is much more convenient to have IPC style access to files, e.g. Accent with its ports, than viceversa, unless we are so wedded to UNIX that we cannot change (probably true, vide failure of Accent to get accepted, and then success of Mach, which is a Unix like imitation of it). Frankly, the "everything is a file" way of achieving connectability is not the best abstraction, because you want to connect to active services, not just to passive storage. Straining a file model to include "active" files is a bit inelegant. "everything is a socket" or equivalently "everything is a process" (even files!) are much better; "everything is a file system", the technology used in recent research Unixes or PLAN/9 is a way to get as abstraction a more active thing than a file, works better than "everything is a file", yes, but requires a large suspension of disbelief, and assumes that we really want the Unix directory tree model for all name service, which may not be a terribly good choice either. e.g. as in having an internet filesystem type, and doing something like fd = open("/dev/internet/lcs.mit.edu/echo.udp",...); /*or*/ fd = open("/dev/internet/edu/mit/lcs/119.tcp",...); sklower> I find this inaccurate, partronizing and tiresome. I have sklower> worked around Berkeley since 1978 and although was not a member sklower> of the actual unix group in 1982 while TCP was being sklower> incorporated, attended their meetings and seminars. Ahh. Incidentally, I would like to observe that I have *never* seen an implementation of BSD sockets and TCP. The only ones that circulate are extremely limited and rigid subsets. Since you have been around UCB for so long, can you tell us why there is no (full) implementation of BSD sockets? E.G. where are user domain type filedescriptors? About compatibility between IPC and normal file I/O: sklower> I assure you that it was the design goal then, that only sklower> ``sophisticated process'' would need a more elaborate mechanism sklower> to establish a network connection, but that once having sklower> established one, that it should be usable as a completely sklower> ordinary file descriptor by ``naive'' processes like the date sklower> command, using read and write, and that the file descriptor sklower> should be inherited by the normal unix means (fork & exec). Uhm. Precisely. And 'wrappers', one of the features of BSD sockets, were designed to make such compatibility absolute. Why nobody has ever implemented them? sklower> It sounds to me like Henry is attempting to rewrite history sklower> (for his own possibly political motives). I actually think that he may innocent, but he *is* attempting to rewrite history, in a way different from what you say; on BSD it actually happens that read/write on sockets is the same as on files, but because they changed the specification of read/write on files. The only difference with send/rcv is that sendmsg/rcvmsg allow out-of-band, and passing file descriptors, which make no sense with read/write to a file, but the distance from traditional read/write is larget than that. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk