On 9/21/17 12:01 PM, Ian Zimmerman wrote: AT&T merged the sockets interface into SVR4, starting with the BSD code. Sun did the work. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

Ian Zimmerman writes: Maybe this is naive of me, but I have never liked parts of the sockets interface. I understand that at some level it was a political/legal keeping the networking code independent of the rest of the kernel. the iceberg bloating the number of system calls. In particular, I have often thought that it would have been a better and more consistent with the philosophy to have it implemented as open("/dev/tcp") and so on. Granted that networking added some new functionality that justified some of the system calls, just not socket(). Comments? Jon

On Thursday, 2017-09-21 at 09:10:40 -0700, Larry McVoy wrote: You could pop the socket module to get to the stream underneath, but lots of streams functionality still works with it present. dme. -- Modern people tend to dance.

On Thu, Sep 21, 2017 at 12:25:13PM -0400, Clem Cole wrote: +1 I've always tried to make it clear that dmr's streams != Sys V STREAMS. I thought dmr streams were cool, I detest the Sys V STREAMS.

On 9/21/17 12:10 PM, Larry McVoy wrote: Here's an article describing the work Sun did (whether it started at Mentat or not) to initially provide the socket interface on SVR4: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.7181&rep=re… It was my impression that they started with the BSD kernel implementation and used it to create `socklib' and `sockmod'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

sockets and streams, but what about tli (i think) transport level interface - that exists in one of the sys-v variants. maybe that was streams and i just didn't realise or maybe it was something else? -Steve

you can go back and find an early RFC which discusses the notion of /dev/tcp etc. I think I referenced it the last time this question came up. In that rfc, the idea of /dev/tcp and so on was advanced. To connect to harv, one might create /dev/tcp/harv, for example. It was not quite right. How do you name a port? What file system operation in Unix corresponds to what socket operation? There were lots of efforts from 77 or so on to get sockets APIs done in a Unix style, i.e. not the style we ended up with, but AFAIK nobody really worked it out until Plan 9 did it. While it is true that socket()/bind/listen/accept/connect have stood the test of time, I know when they were introduced many people thought of that API as the first break in the Unix model, and a wrong turn, one that was never fixed. It's very easy to create a "file system" model for the network in a way that doesn't make sense, e.g. if I have /dev/tcp/harv, and mv it to /dev/tcp/prep, does that mean I close the connection to harv and open one to prep? And so on. These issues were covered really nicely in a talk Rob Pike gave in the 90s, but I can't find those slides any more and neither can he. They're probably still on the venti server in the Unix room ... :-) For an example of (IMHO) not getting it right, see: http://www.cs.vu.nl/~herbertb/papers/osreview2008-2.pdf I think anyone looking to put something like a network stack in the name space should study on what Plan 9 did, not because it's the "right" or "only' way to do it, but it's a way that worked. But overall, in the 1977 timeframe, when (IIRC) there were no synthetic file systems, I think we did not know how to think about "networks in the file system" and we got what we got. By the time it was worked out, well, it was too late to change.

There's no reason it could not be done literally with entries similar to /dev ones, since each socket() takes some arguments (domain, type, protocol) which could be represented as directly as: /socket/domain/type/protocol_or_default for instance. For the typical s = socket(PF_INET, SOCK_STREAM, 0) you would open "/socket/inet/stream/tcp". To distinguish between UDP and RDP you'd open "/socket/inet/dgram/udp" vs "/socket/inet/dgram/rdp". Of course these days there's a <type> constant for reliable datagram, and some of these are just overcomplicating things: /socket/inet/tcp, /socket/inet/icmp, etc., would actually suffice, but there's an obvious one to one mapping from "socket" arguments to strings under "/socket" or whatever top level name you want. More fundamentally, a socket itself is only "half initialized". It's neither bound to any local address, nor connected to any remote address. The BSD kernel interface introduced two system calls, bind() and connect(), to let you specify these two halves. But these two calls are wrong! It needs to be *one* call, that does both operations simultaneously, so as to allow you to specify that you want the system to provide the local or remote address. You supply one or both. To supply only one, pass in a NULL for the other one. * You supply only the remote address: "I want to connect to someone and I know their address, so just pick a local one that works." This is currently written as connect(). * You supply only the local address: "I want to be a server." This is currently written as bind() followed by listen() followed by a series of accept()s. There's no reason for a separate listen() call (it takes a "backlog" argument but in practice everyone defaults it and the kernel does strange manipulations on it.) This also knocks out the need for SO_REUSEADDR, because the kernel can tell at the time of the call that you are asking to be a server. Either someone else already is (error) or you win (success). * You supply both halves at the same time. (This is the special case FTP requires.) "I want to connect to someone and I know he expects me to be address <L>.") This is a rare special case. We need a way to reserve an address. But it's rare, let's make *it* the complicated one. If you supply both halves at the same time, you can pass pointers to two all-zero addresses, both local and remote. This is different from passing in a NULL ("I don't care"): it means "I do care, get me an address" (reserving it) along with "I can't actually connect yet". Now you have the "3/4ths done" socket. You know what your local address will be. You give this to the remote, and call the system call again with the other guy's IP address this time. That's not optimal (sometimes the local address you want to use depends on the remote address you will use), but it's what the existing system calls give you anyway, as you can't call connect() first, you must call bind() first. Also, the profusion of system calls (send, recv, sendmsg, recvmsg, recvfrom) is quite unnecessary: at most, one needs the equivalent of sendmsg/recvmsg. So we could right away do this: bind(), listen(), connect() => setconn() send(), sendmsg() => sendmsg() recv(), recvfrom(), recvmsg() => recvmsg() even without figuring out how to properly implement /dev/tcp or whatever. Of course, it's a bit late. :-) Chris