[TUHS] Research Datakit notes
tjteixeira at earthlink.net
Wed Jun 29 02:11:10 AEST 2022
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.
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
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.
More information about the TUHS