On Sun, Jul 3, 2022 at 1:33 PM Marc Donner <marc.donner(a)gmail.com> wrote:
On June 28 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."
I've been ruminating on the question of whether networks are different
from disks (and other devices). Here are a couple of observations:
1 - Two different packets may take two different paths from the sender to
the receiver.
Yes, but it doesn't much matter. It's a solved problem.
1a - The transit time for one packet may vary widely from that of the other.
Yes, but it doesn't much matter. This too
is a solved problem.
1b - The two packets may arrive in an order different from the order in
> which they were transmitted.
Yes, but TCP will present the data they describe
in order, or an error.
(Note - recently I have been reading Bob Gezelter's monograph [and PhD
> dissertation] and I've learned that modern high-performance disk systems
> behave more like networks in 1a and 1b.)
> 2 - A packet may never arrive.
TCP will retry lost data, and if transmission
continues failing, TCP'll
give an error.
3 - Behavior 2 not a sign of hard failure for networks, whereas it is
> generally considered so for other I/O devices.
Network API's and protocols aren't all
the same. You seem to be thinking
of UDP or IP or something.
There is probably more to why networks are weird, but these are some of the
> big dissonances that seem to me to make Rob's comment resonate so loudly to
> me.
TCP really isn't that bad, and REST is
simpler still.
The chief problem with TCP that people get wrong is:
https://stromberg.dnsalias.org/~strombrg/TCP/