From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25017 invoked from network); 3 Jul 2022 20:59:07 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2022 20:59:07 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 475F440784; Mon, 4 Jul 2022 06:58:46 +1000 (AEST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by minnie.tuhs.org (Postfix) with ESMTPS id 29DA04076F for ; Mon, 4 Jul 2022 06:58:42 +1000 (AEST) Received: by mail-pf1-f176.google.com with SMTP id 65so7270404pfw.11 for ; Sun, 03 Jul 2022 13:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/o6YJIC4WnVWR6UBtyPRbsxOIqKTQ6Et3sxTCzM7ZAo=; b=kL1BHEIZyx9hVBKElW+sFDBd4k4tOPNsU307eCtBnblU50L3U9pkP8Q6O4XxMM1FFV 9wVmEWe28P5GkG4N91BM2q7E/WmSgS0jpsc2Qx5Md9QF23k5Y8y6Be1dLI9DqsXd+44a SKX2dHMoXbvghYrVs+u0qfPaUs7FQzxIpYJ5S1beQPjExapMk54NeMyBJsxnEBNVpbkA 44hf0GH0aBE2gjcF5EH/dHec1Mcb7EKwhLg0ZtE7rMrhhcdHDvqi8q7PAxt56deSUFyu RwJSNhlUgI6TkKJo5ZVBNdQ4MWGgo2xTTqNyeypdHBuZ+loijqYW+M6Ek1ecXCjHRx+L 3oVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/o6YJIC4WnVWR6UBtyPRbsxOIqKTQ6Et3sxTCzM7ZAo=; b=CfDfeAjsKKCQZ6m/Mb2a/fTyFK57KgFhw5x9a7Vl9o4DTRoEZVNeA4wp8AEmKotFbJ KtWFyEPUqLsxNVvVDjeVAe3XlTxLaB86XUclUpG0DSpwkBXxXQTnfFxri1OoqPa0CzH6 ETRR9REBckVh0+bqC6wFATU7oMjUs9UvtfpDSnnOpesfEfrtVevN5U4Vp47RkYOKBQuP zluuzmr0Dd3vPDSeTOLBxcBhck/PdBUTSlp+1giWmsVFSHnY+UcSLdwsDEWtyZFgNy5Q a4QISSKoXZ0L9VctpZB9OiT3reW6JwURUkXGBvasadUzMUwi92y/7lXfwHXdP4INlEM6 gA/w== X-Gm-Message-State: AJIora9Q/A2j6bNxi8pmp6PnZ6FXGl5dLrz8YYZQ8wPoKbbrp/DFmmU8 ahKwb1LbYFNrwefZfMJZVHSLxumAoJlJ5R7xfa0= X-Google-Smtp-Source: AGRyM1vKn85pWvJwXErsrxRPeu1v9P4EhasjEu3WlmvuGzHxAazPClv4NQ/CfZIPkT21vCJ/rrDLyMhQIoxtQhnpFsY= X-Received: by 2002:a63:6984:0:b0:40d:9ebe:5733 with SMTP id e126-20020a636984000000b0040d9ebe5733mr22525256pgc.170.1656881861468; Sun, 03 Jul 2022 13:57:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Stromberg Date: Sun, 3 Jul 2022 13:57:30 -0700 Message-ID: To: Marc Donner Content-Type: multipart/alternative; boundary="000000000000c9a5d505e2ecdea5" Message-ID-Hash: D644QJ4TNXVR646XVNYASFU5RMEOGHFM X-Message-ID-Hash: D644QJ4TNXVR646XVNYASFU5RMEOGHFM X-MailFrom: drsalists@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: is networking different? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c9a5d505e2ecdea5 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 3, 2022 at 1:33 PM Marc Donner 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/ --000000000000c9a5d505e2ecdea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jul 3, 2022 at 1:33 PM Marc Donne= r <marc.donne= r@gmail.com> wrote:
On June 28 Rob Pike wrote:

"One of the reasons I'm not a netwo= rking expert may be relevant here. With networks, I never found an abstract= ion to hang my hat on. Unlike with file systems and files, or even Unix cha= racter 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 blo= cks and sectors themselves."

I've been ruminating on the question of whether = networks are different from disks (and other devices).=C2=A0 Here are a cou= ple of observations:

1 - Two different packets may take two different paths from the s= ender to the receiver.
Yes, but it doesn't= much matter.=C2=A0 It's a solved problem.

1a - The transit time f= or one packet may vary widely from that of the other.
Yes, but it doesn't much matter.=C2=A0 This too is a solved pro= blem.

1b - The two packets may arrive in an order different from the or= der in which they were transmitted.
Yes, but T= CP will present the data they describe in order, or an error.

(Note - re= cently I have been reading Bob Gezelter's monograph [and PhD dissertati= on] and I've learned that modern high-performance disk systems behave m= ore 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 networ= ks, whereas it is generally considered so for other I/O devices.
Network API's and protocols aren't all the same.= =C2=A0 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 t= hat seem to me to make Rob's comment resonate so loudly to me.
TCP really isn't that bad, and REST is simpler sti= ll.

The chief problem with TCP that people get wr= ong is:
https:= //stromberg.dnsalias.org/~strombrg/TCP/

--000000000000c9a5d505e2ecdea5--