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_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20700 invoked from network); 28 Jun 2022 17:44:15 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 28 Jun 2022 17:44:15 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7A08340140; Wed, 29 Jun 2022 03:43:53 +1000 (AEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by minnie.tuhs.org (Postfix) with ESMTPS id D985A40065 for ; Wed, 29 Jun 2022 03:43:47 +1000 (AEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B3A833200933 for ; Tue, 28 Jun 2022 13:43:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 28 Jun 2022 13:43:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= johnlabovitz.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1656438226; x=1656524626; bh=kOB3eWktJ+bj7/44e7oKh3IT6 fFsZHPDjtFQhQHGB3U=; b=Ccpx/BJx6wSff57+B4GTHbsGCBfEpucl3RjHPNDoC MaFnTm+1Qdm8BcyWhVj4i9FQO6auFpVt9O2r5vSjbIV4f8+NxuIfpEHQd7wWITju IHNCh3MclW4BLkz5Sy+SzSxhZKe34QHa5JXPGCpwpinbkHXynQK6Qp3RYt3/Ktvu k4KN+14kmLlHbb6C02woREaYH9xj58RB25eqlzPu620ft+0bqL711ntFCehrUt/w aU0olPFbWxcFX3YNJAgdpbjikr6x/WpwklrOVr3n4PMN/9v16Ej1+fMsaQq2FvIE /lf7GTOtS/nQHhUxutzkKLDVnzajNMQ5u6fZY+WlBe2GQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1656438226; x=1656524626; bh=k OB3eWktJ+bj7/44e7oKh3IT6fFsZHPDjtFQhQHGB3U=; b=lUgBRr1NUpV+CEd5w db0U+16wEjdHb1eQJ4HZg/eV8JvSFWxI1oYyKcWRpEwAS1g4aonajJ8cQ8wIQ5cm 97E7ld4IcXlXEWKEcJzXbbb/0h60WbH+zj7HCq0DzJ4KAEuQgpDlrbKWLWcPzb7d o1VWrGIncy4pIHm71m1dS1EbKpK/TBTLjs6YlmBX/LtqS4XAglrtydLp5/yoFQ86 HKg0oNojjHq0u8Bogp91aQ8ftekdURFtpxCuXzUpcWtjJ2pueQwt+rWUr8lEDM+U FkO16u+MsF0R0Hkbi6dkpDA1NlK/xSQRjUKn7GRrs56NZK0c042RekUpDtMJHRse uGK3A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegjedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephfgtgfgguffffhfvjgfkofesth hqmhdthhdtjeenucfhrhhomheplfhohhhnucfnrggsohhvihhtiicuoehjohhhnhhlsehj ohhhnhhlrggsohhvihhtiidrtghomheqnecuggftrfgrthhtvghrnhepheeujeffkedttd ffteegteektddvvdehgfettefghfffvefhfedvvedtjeettedtnecuffhomhgrihhnpegu rhgvrghmfihiughthhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehjohhhnhhlsehjohhhnhhlrggsohhvihhtiidrtghomh X-ME-Proxy: Feedback-ID: i69c041ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Jun 2022 13:43:45 -0400 (EDT) From: John Labovitz Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Date: Tue, 28 Jun 2022 19:43:44 +0200 References: <2803DC51-6CBC-4257-B40C-8A559C27CAE3@planet.nl> <20220625230939.GG19404@mcvoy.com> <0CA3B3AA-6491-47A5-843D-CDF2F3A74659@cfcl.com> <76DD5063-3817-4550-980A-66E728DFD634@gmail.com> To: The Eunuchs Hysterical Society In-Reply-To: <76DD5063-3817-4550-980A-66E728DFD634@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3696.100.31) Message-ID-Hash: ZFZZWJVDVEQWPBG5KTBDR6JVICCYPZEN X-Message-ID-Hash: ZFZZWJVDVEQWPBG5KTBDR6JVICCYPZEN X-MailFrom: johnl@johnlabovitz.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 X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Research Datakit notes List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: I=E2=80=99m generally a lurker here, but this has been an interesting = conversation to observe. I often hesitate to post, as to not offend you = folks who literally invented this stuff, but I thought it might be = helpful to share some experiences with socket-based I/O. For the first time in ~20 years, I=E2=80=99ve recently been writing = low-level (eg, not through a library layer/framework) socket code in = straight C, for an art project based on an ESP32 embedded/SoC. I first = played around with the socket API in the mid-80s, and then wrote a lot = of socket-using code in the 1990s for the Watchguard Firebox, the first = Linux-based appliance firewall. I have to say that I really enjoying programming with sockets. I feel = that it *does* make a lot of sense if I'm thinking directly about the = TCP/IP stack, *and* if my code has a good 'impedance match' to the = protocols. If I=E2=80=99m writing a server, I=E2=80=99m dealing with = connections and queues and various-sized packets/messages/blocks, which = have to fit into some decision of memory usage (often true in embedded = systems). Usually I=E2=80=99m not simply writing, say, a file server = that simply reads from disc and sends bytes out through a stream and = then calls close(). I also believe that the sockets API really comes into its own with = high-capacity, non-threaded, non-blocking servers or clients =E2=80=94 = that is, ones that use select() or poll() and then recv() and send() or = their variants. I=E2=80=99m sure that if I didn=E2=80=99t have a sockets = API and only had open(), read(), write(), etc., I could make it work, = but there=E2=80=99s something almost beautiful that happens at a large = scale with many non-blocking sockets (see: the reactor pattern) that I = don=E2=80=99t think would translate as well with a typical = everything-is-a-file model. My opinion solely, of course. But I=E2=80=99m simply happy that both = socket- and file-based APIs exist. Each has their purpose. =E2=80=94John > On Jun 28, 2022, at 19:05, Adam Thornton wrote: >=20 >=20 >=20 >> On Jun 28, 2022, at 6:13 AM, Marc Donner = wrote: >>=20 >> What I don't understand is whether Rob's observation about networking = is *fundamental* to the space or *incidental* to the implementation. I = would love to be educated on that. >=20 > And there it is! THAT was the sentence--well, ahort paragraph--that = jogged my memory as to why this seemed familiar. >=20 > If you go back to _The Unix-Hater's Handbook_ (I know, I know, bear = with me), one of the things I noticed and pointed out in my review = (https://athornton.dreamwidth.org/14272.html) is how many of the targets = of hatred, twenty years down the line, turned out to be unix-adjacent, = and not fundamental. >=20 > In the book, these were things like Usenet and sendmail.cf (indeed, = those were the two big ones). >=20 > But the current discussion: is the thing we don't like Berkeley = Sockets? Is it TCP/IP itself? Is the the lack of a Unixy abstraction = layer over some lower-level technology? To what degree is it inherent? >=20 > I mean, obviously, to some degree it's all three, and I think a large = but fairly unexamined part of it is that TCP/IP these days almost always = at least pretends to be sitting on top of Ethernet at the bottom...but = of course Classic Ethernet largely died in the...early 2000s, I = guess?...when even extremely cheap home multiple-access-devices became = switches rather than hubs. >=20 > Some sort of inter-machine networking is clearly inherent in a modern = concept of Unix. I think we're stuck with the sockets interface and IP, = whether we like them or not. They don't bother me a great deal, but, = yes, they do not feel as unixy as, say, /dev/tcp does. But the = interesting thing is that I think that is Unix-adjacent or, like the UHH = distate for Unix filesystems, it's at least incidental and could be = replaced if the desire arose. And I think we already have the answer = about what the abstraction is, albeit at an application rather than the = kernel level. >=20 > To answer Rob's question: I think the abstraction is now much farther = up the stack. To a pretty good first approximation, almost all = applications simply definte their own semantics on top of HTTP(S) (OK, = OK, Websockets muddy the waters again) and three-to-five verbs. There's = an incantation to establish a circuit (or a "session" if you're under = the age of 50, I guess), and then you GET, DELETE, and at least one of = PUT/POST/PATCH, for "read", "unlink", and "write". This does seem to be = a more record-oriented (kids these days get snippy if you call them = "records" rather than "objects" but w/e) format than a stream of bytes = (or at least you put an abstraction layer in between your records and = the stream-of-octets that's happening). >=20 > This is certainly not efficient at a wire protocol level, but it's a = fairly small cognitive burden for people who just want to write = applications that communicate with each other. >=20 > Adam