[TUHS] Re: Research Datakit notes

[Tom Teixeira <tjteixeira@earthlink.net>]

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.