The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Stromberg <drsalists@gmail.com>
To: Marc Donner <marc.donner@gmail.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: is networking different?
Date: Sun, 3 Jul 2022 13:57:30 -0700	[thread overview]
Message-ID: <CAGGBd_r3exOrGzEhiZng_uYyvuE2EWtjReEz0EgaaY2bG2SHQg@mail.gmail.com> (raw)
In-Reply-To: <CALQ0xCAX4LZALeVBvVK-D3szZTB9DU_G7cs__1S_tMbPjHPivA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On Sun, Jul 3, 2022 at 1:33 PM Marc Donner <marc.donner@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/

[-- Attachment #2: Type: text/html, Size: 4331 bytes --]

  parent reply	other threads:[~2022-07-03 20:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-03 20:32 [TUHS] " Marc Donner
2022-07-03 20:34 ` [TUHS] " Marc Donner
2022-07-03 20:57 ` Dan Stromberg [this message]
2022-07-03 21:55   ` Richard Salz
2022-07-04 20:09 [TUHS] Re.: " Paul Ruizendaal via TUHS
2022-07-04 21:17 ` [TUHS] " ron minnich
2022-07-04 23:37   ` [TUHS] " Paul Ruizendaal
2022-07-05  3:02     ` John Cowan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGGBd_r3exOrGzEhiZng_uYyvuE2EWtjReEz0EgaaY2bG2SHQg@mail.gmail.com \
    --to=drsalists@gmail.com \
    --cc=marc.donner@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).