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 14819 invoked from network); 28 Jun 2022 12:47:04 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 28 Jun 2022 12:47:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 727FA40C95; Tue, 28 Jun 2022 22:46:27 +1000 (AEST) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by minnie.tuhs.org (Postfix) with ESMTPS id 1009C40C5E for ; Tue, 28 Jun 2022 22:46:23 +1000 (AEST) Received: by mail-vs1-f45.google.com with SMTP id j6so11934778vsi.0 for ; Tue, 28 Jun 2022 05:46:23 -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=sg3gL0d5uBJ7lfwD3/zwWvNy+HiMujSFaEJiB/tLeK4=; b=pLsZ1FsIgo/h61uLK+/xOqkTbjRPSNwWYGHcZcASMx9zaFczwR/A6Ja7Er2o8vAHsr TJOW0oLEfIl3smvwJWQOipMNIbtgIVQKNOLZsGT6xUx5RuXG2oAPvEQdoESjYC8UtOWQ osL4pqn29beIwKK7lhOza6SWICWTgXyLS/zWqU6Vo6T3EJzKkf+inj+hz3NU+sTeIpQh GeGINgB3yIsY2q+Y9sdwb6Gpb01EziH8A9gb8foDZjwWPtWpFoZWuS1Xm6Xyh3F/ymWc 42mPbtY20AOzb1KDOI3XhiQkfAWRJoASbgT5VWK7cZIgFGc7DIw00MmaHcSAfQk2Q/lm BlQA== 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=sg3gL0d5uBJ7lfwD3/zwWvNy+HiMujSFaEJiB/tLeK4=; b=zbSpCcECzdDZRFN29JfaDQJZZMIh6oX02gsrRv2nrx8Eegx5ZRCw/7MadoQhKuUaGS yNVD58lklC0xV4O8J18oJevai0WpOqV41+AT/7nqlhHdLqEIWSyYwc42mXX2zSACgECQ sj+o+g4NbjHAGdkSZLgiRx7rbitFKR/j3YKawWLewGe78fvTC1mMjzeFYproXrDs96bU zBl5nS7qeoImqykcwJcJrNFcevlZjDTsFAyiHYwqH1sgwwF3ytcX7Xmb0taQGBmw8gds jRO7PN9R6Eyoe5O4OAf7PcK959PKDBmMhV//YfRTcd5MT2hYR5yz1ahzh1cy8RJ04Ar9 gqtA== X-Gm-Message-State: AJIora8OZ0yzMjWh0L2/BJih5sZ+B0Fl6RdjhxT6Eyq9NWkOF5eoc3Ue XkS6h1PDsglIPW4PgOtpI8sHqCKXZHDs+9PKGgYB19v1 X-Google-Smtp-Source: AGRyM1tzesZwNMUhp5P66S7UmaUiOJuSNz/UMzCvzVjkOdn3g05z6+rYOWPbHSuirSIS1bxTrSsydr6sJfU3rpdwmxk= X-Received: by 2002:a05:6102:5120:b0:356:3800:dd94 with SMTP id bm32-20020a056102512000b003563800dd94mr1195762vsb.83.1656420322000; Tue, 28 Jun 2022 05:45:22 -0700 (PDT) MIME-Version: 1.0 References: <2803DC51-6CBC-4257-B40C-8A559C27CAE3@planet.nl> <20220625230939.GG19404@mcvoy.com> In-Reply-To: From: Rob Pike Date: Tue, 28 Jun 2022 22:45:11 +1000 Message-ID: To: Derek Fawcus Content-Type: multipart/alternative; boundary="000000000000e4434105e2816827" Message-ID-Hash: RHWYNHY4B7YKBWNJGRNOAPCARNAM3DYO X-Message-ID-Hash: RHWYNHY4B7YKBWNJGRNOAPCARNAM3DYO X-MailFrom: robpike@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: 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: --000000000000e4434105e2816827 Content-Type: text/plain; charset="UTF-8" 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. It just seems there has to be a better way. Sockets are just so unpleasant, and the endless nonsense around network configuration doubly so. Rhetorical questions. I'm not asking or wanting an answer. I'm happy to remain a greenhorn, oblivious to the wonder. To adapt a reference some may recognize, I just want to read 5 terabytes. -rob On Tue, Jun 28, 2022 at 10:36 PM Rob Pike wrote: > I am not a networking expert. I said that already. The issue could well be > a property more of sockets than TCP/IP itself, but having the switch do > some of the call validation and even maybe authentication (I'm not sure...) > sounds like it takes load off the host. > > -rob > > > On Tue, Jun 28, 2022 at 8:39 PM Derek Fawcus < > dfawcus+lists-tuhs@employees.org> wrote: > >> On Sun, Jun 26, 2022 at 09:57:17AM +1000, Rob Pike wrote: >> > One of the things we liked about Datakit was that the computer didn't >> have >> > to establish the connection before it could reject the call, unlike >> TCP/IP >> > where all validation happens after the connection is made. >> >> Nor does TCP, one can send a RST to a SYN, and reject the call before it >> is >> established. That would then look to the caller just like a non listening >> endpoint, unless one added data with the RST. >> >> So this is really just a consequence of the sockets API, and the current >> implementations. >> I've a vague recall of folks suggesting ways to expose that facility via >> the sockets >> layer, possibly using setsockopt(), but don't know if anyone ever did it. >> >> As I recall that TCP capability was actually exposed via the TLI/XTI API, >> and (for some STREAMS based TCP stacks) it did function. Although I may be >> thinking of embedded STREAMS TCP stacks, not unix based stacks. >> >> Or by 'connection' are you referring to an end-to-end packet delivery, >> and that Datakit allowed a closer switch to reject a call before the >> packet >> got to the far end? >> >> DF >> > --000000000000e4434105e2816827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 o= n. Unlike with file systems and files, or even Unix character devices, whic= h provide a level of remove from the underlying blocks and sectors and so o= n, the Unix networking interface always seemed too low-level and fiddly, an= alogous to making users write files by managing the blocks and sectors them= selves. It could be all sockets' fault, but when I hear networking peop= le 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 inte= rface had send and recv, not read and write. From day 1 in Unix land at lea= st, networking was special, and it remains so, but I fail to see why it nee= ds to be.

It just seems there has to be a better way. So= ckets are just so unpleasant, and the endless nonsense around network confi= guration doubly so.

Rhetorical questions. I'm n= ot asking or wanting an answer. I'm happy to remain a greenhorn, oblivi= ous to the wonder.

To adapt a reference some may r= ecognize, I just want to read 5 terabytes.

-rob


On Tue, Jun 28, 2022 at 10:36 PM Rob Pike <= ;robpike@gmail.com> wrote:
<= /div>
I a= m not a networking expert. I said that already. The issue could well be a p= roperty more of sockets than TCP/IP itself, but having the switch do some o= f the call validation and even maybe authentication (I'm not sure...) s= ounds like it takes load off the host.

-rob

On Tue, Jun 28, 2022 at 8:39 PM Derek Fawcus <dfawcus+lists-tuhs@em= ployees.org> wrote:
On Sun, Jun 26, 2022 at 09:57:17AM +1000, Rob Pike wrote:
> One of the things we liked about Datakit was that the computer didn= 9;t have
> to establish the connection before it could reject the call, unlike TC= P/IP
> where all validation happens after the connection is made.

Nor does TCP, one can send a RST to a SYN, and reject the call before it is=
established.=C2=A0 That would then look to the caller just like a non liste= ning
endpoint, unless one added data with the RST.

So this is really just a consequence of the sockets API, and the current im= plementations.
I've a vague recall of folks suggesting ways to expose that facility vi= a the sockets
layer, possibly using setsockopt(), but don't know if anyone ever did i= t.

As I recall that TCP capability was actually exposed via the TLI/XTI API, and (for some STREAMS based TCP stacks) it did function. Although I may be<= br> thinking of embedded STREAMS TCP stacks, not unix based stacks.

Or by 'connection' are you referring to an end-to-end packet delive= ry,
and that Datakit allowed a closer switch to reject a call before the packet=
got to the far end?

DF
--000000000000e4434105e2816827--