On Thu, Sep 21, 2017 at 12:10 PM, Larry McVoy <lm(a)mcvoy.com> wrote: ​Larry is being polite. It sucked.​ ​ It was never designed for it. dmr designed Streams to replace the tty handler. I never understood why the Summit guys insisted on forcing networking into it.​ ​Right. This is one of the places where SVR4 != Solaris I was researching a book a long time ago and looked at this. I had Solaris, SVR4 and some other stuff at the time. Like you bit rot has long set in on the details, but I do remember that the primary thing that Solaris had was support for Sun's threading model and the networking code had to be a first class citizen ​or it was not going to scale.

Clem Cole writes: I have never had any reason to dig into the streams code. But there is one part of the implementation that I hate, which is the way that data is lost when switching between modules. This most notably rears its ugly head when using something like vi, hitting control-Z, and then typing a shell command. The user has to pause because incoming characters get tossed when switching from cbreak to cooked. This has become less of an issue as machines have gotten faster, but it still gets me if my system is extremely heavily loaded. Jon

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

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.

On Thu, 21 Sep 2017, Jon Steinhart wrote: An old Unix manual referred to preferring "/dev/net" but that would've been a 9-track even parity tape drive under the nomenclature at the time... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."