28 Jun
2022
28 Jun
'22
6:11 p.m.
On 6/28/22 8:45 AM, Rob Pike wrote:
One of the reasons I'm not a networking expert
may be relevant here.
With networks, I never found an abstraction to hang my hat on. Unlike
with file systems and files, or even Unix character devices, which
provide a level of remove from the underlying blocks and sectors and
so on, the Unix networking interface always seemed too low-level and
fiddly, analogous to making users write files by managing the blocks
and sectors themselves. It could be all sockets' fault, but when I
hear networking people talk about the protocols and stacks and routing
and load shedding and ....my ears droop. I know it's amazing
engineering and all that, but why aren't we allowed to program the I/O
without all that fuss? What makes networks so _different_? A telling
detail is that the original sockets interface had send and recv, not
read and write. From day 1 in Unix land at least, networking was
special, and it remains so, but I fail to see why it needs to be.
Two observations:
At the time, I think everyone was searching for the right abstraction. I
don't remember the whole talk, but just an anecdote by, I think, David
Clark. I don't remember if this was just a seminar at MIT LCS or perhaps
at SIGOPS. In any case, David talked about trying to get some database
people to use the virtual memory and file systems abstractions that had
been built by Multics. They agreed that these were nice abstractions,
but in the mean time, "get out of our way and let us at the disk."
Since networking developers and users were all searching for the right
abstraction, and new hardware, protocols, and software interfaces were
being proposed on what seemed like a weekly basis, many of the proposed
interfaces tried to expose low level mechanisms as well as high level
stream abstractions, preserving the hope that something like TCP could
be implemented at user code level rather than the kernel.
Secondly, I had to dig up a reference for the Chaosnet software (MIT AI
memo 628 available at
http://bitsavers.trailing-edge.com/pdf/mit/ai/AIM-628_chaosnet.pdf and
probably other places). The Unix implementation used the rest of the
path name to specify connection setup parameters in the typical case
which seemed more unix-like than sockets. But the Chaosnet software was
definitely swept away in the Ethernet/sockets storm surge.