The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re.: is networking different?
@ 2022-07-04 20:09 Paul Ruizendaal via TUHS
  2022-07-04 20:44 ` [TUHS] " Larry McVoy
  2022-07-04 21:17 ` ron minnich
  0 siblings, 2 replies; 7+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-07-04 20:09 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote:
> 
> I've been ruminating on the question of whether networks are different from
> disks (and other devices).  Here are a couple of observations:

[...]

From my perspective most of these things are not unique to networks, they happen with disks and/or terminals. Only out-of-order delivery seems new. However, in many early networking contexts (Spider/Arpanet/Datakit/UUCP) this aspect was not visible to the host (and the same holds for a single segment ethernet).

To me, in some ways networks are like tty’s (e.g. completing i/o can take arbitrarily long, doing a seek() does not make sense), in other ways they are like disks (raw devices are organised into byte streams, they have a name space). Uniquely, they have two end-points, only one of which is local (but pipes come close).

Conceptually, a file system does two things: (i) it organises raw blocks into multiple files; these are the i-nodes and (ii) it provides a name space; these are directories and the namei routine. A network stack certainly does the first: a raw network device is organised into multiple pipe-like connections; depending on the network, it optionally offers a naming service.

With the first aspect one could refer to any file by “major device number, minor device number, i-node number”. This is not very different from referring to a network stream by “network number, host number, port number” in tcp/ip (and in fact this is what bind() and connect() in the sockets API do), or “switch / host / channel” in Datakit. For disks, Unix offers a clean way to organise the name spaces of multiple devices into a unified whole. How to do this with networks is not so easy, prior to the invention of the file system switch.

Early on (Arpanet Unix), it was tried to incorporate host names into a net directory by name (RFC 681) but this is not scalable. Another way would be to have a virtual directory and include only names for active connections. The simple way would be to use a text version of the numeric name as described above - but that is not much of an improvement. Better to have a network variant of namei that looks up symbolic names in a hosts file or in a network naming service. The latter does not look very performant on the hardware of 40 years ago, but it appears to have worked well on the Alto / PuPs network at Xerox PARC.

With the above one could do

open(“/net/inet/org.tuhs.www:80”, O_RDWR | O_STREAM)

to connect to the TUHS web server, and do

open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600)

to create a ‘listening’ (rendez-vous) socket.

Paul













^ permalink raw reply	[flat|nested] 7+ messages in thread

* [TUHS] Re: Re.: is networking different?
  2022-07-04 20:09 [TUHS] Re.: is networking different? Paul Ruizendaal via TUHS
@ 2022-07-04 20:44 ` Larry McVoy
  2022-07-04 21:31   ` Paul Ruizendaal via TUHS
  2022-07-04 21:33   ` Phil Budne
  2022-07-04 21:17 ` ron minnich
  1 sibling, 2 replies; 7+ messages in thread
From: Larry McVoy @ 2022-07-04 20:44 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: The Eunuchs Hysterical Society

On Mon, Jul 04, 2022 at 10:09:52PM +0200, Paul Ruizendaal via TUHS wrote:
> With the above one could do
> 
> open("/net/inet/org.tuhs.www:80", O_RDWR | O_STREAM)
> 
> to connect to the TUHS web server, and do
> 
> open("/net/inet/any:80", O_RDWR | O_STREAM | O_CREAT, 0600)
> 
> to create a "listening" (rendez-vous) socket.

Decades ago, I tried to make a library that worked like this and it
was problematic.  There are all sorts of setsockopt things that
you sometimes need to set.

I'd love to be wrong on this, if anyone has a working, for all of the
normal use cases, library like this, I'd love to see it.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [TUHS] Re: Re.: is networking different?
  2022-07-04 20:09 [TUHS] Re.: is networking different? Paul Ruizendaal via TUHS
  2022-07-04 20:44 ` [TUHS] " Larry McVoy
@ 2022-07-04 21:17 ` ron minnich
  2022-07-04 23:37   ` [TUHS] " Paul Ruizendaal
  1 sibling, 1 reply; 7+ messages in thread
From: ron minnich @ 2022-07-04 21:17 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: The Eunuchs Hysterical Society

Something like what you mention: open(“/net/inet/any:80”, O_RDWR |
O_STREAM | O_CREAT, 0600), is actually to be found in an RFC from
around that time.

You can do that, but the 1980s tried it and it did not end well.
What's it mean, for example, when you rename("/net/harv") to
("/net/google") -- close and reopen socket? (there's a Lost Talk from,
I think, Rob, that addressed this very question)

While it has its flaws, https://9p.io/sys/doc/net/net.html in my view
is the best example to date of how to get it right. Addresses are
strings, just like paths -- well, they *are* paths in fact. Some of
this path-like nature can be seen in the Go net package today.

Oh, and, as regards how the synthetic file system looks: you never,
never, ever, put an address in the pathname. That's important.

Also consider that if you get it right, you can do all the network IO
you want with cat and echo -- people have written telnet in Plan 9
with those two commands. And, if you get it wrong, well -- you get
socat.

On Mon, Jul 4, 2022 at 1:10 PM Paul Ruizendaal via TUHS <tuhs@tuhs.org> wrote:
>
> > On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote:
> >
> > I've been ruminating on the question of whether networks are different from
> > disks (and other devices).  Here are a couple of observations:
>
> [...]
>
> From my perspective most of these things are not unique to networks, they happen with disks and/or terminals. Only out-of-order delivery seems new. However, in many early networking contexts (Spider/Arpanet/Datakit/UUCP) this aspect was not visible to the host (and the same holds for a single segment ethernet).
>
> To me, in some ways networks are like tty’s (e.g. completing i/o can take arbitrarily long, doing a seek() does not make sense), in other ways they are like disks (raw devices are organised into byte streams, they have a name space). Uniquely, they have two end-points, only one of which is local (but pipes come close).
>
> Conceptually, a file system does two things: (i) it organises raw blocks into multiple files; these are the i-nodes and (ii) it provides a name space; these are directories and the namei routine. A network stack certainly does the first: a raw network device is organised into multiple pipe-like connections; depending on the network, it optionally offers a naming service.
>
> With the first aspect one could refer to any file by “major device number, minor device number, i-node number”. This is not very different from referring to a network stream by “network number, host number, port number” in tcp/ip (and in fact this is what bind() and connect() in the sockets API do), or “switch / host / channel” in Datakit. For disks, Unix offers a clean way to organise the name spaces of multiple devices into a unified whole. How to do this with networks is not so easy, prior to the invention of the file system switch.
>
> Early on (Arpanet Unix), it was tried to incorporate host names into a net directory by name (RFC 681) but this is not scalable. Another way would be to have a virtual directory and include only names for active connections. The simple way would be to use a text version of the numeric name as described above - but that is not much of an improvement. Better to have a network variant of namei that looks up symbolic names in a hosts file or in a network naming service. The latter does not look very performant on the hardware of 40 years ago, but it appears to have worked well on the Alto / PuPs network at Xerox PARC.
>
> With the above one could do
>
> open(“/net/inet/org.tuhs.www:80”, O_RDWR | O_STREAM)
>
> to connect to the TUHS web server, and do
>
> open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600)
>
> to create a ‘listening’ (rendez-vous) socket.
>
> Paul
>
>
>
>
>
>
>
>
>
>
>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [TUHS] Re: Re.: is networking different?
  2022-07-04 20:44 ` [TUHS] " Larry McVoy
@ 2022-07-04 21:31   ` Paul Ruizendaal via TUHS
  2022-07-04 21:33   ` Phil Budne
  1 sibling, 0 replies; 7+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-07-04 21:31 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society


> On 4 Jul 2022, at 22:44, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Mon, Jul 04, 2022 at 10:09:52PM +0200, Paul Ruizendaal via TUHS wrote:
>> With the above one could do
>> 
>> open("/net/inet/org.tuhs.www:80", O_RDWR | O_STREAM)
>> 
>> to connect to the TUHS web server, and do
>> 
>> open("/net/inet/any:80", O_RDWR | O_STREAM | O_CREAT, 0600)
>> 
>> to create a "listening" (rendez-vous) socket.
> 
> Decades ago, I tried to make a library that worked like this and it
> was problematic.  There are all sorts of setsockopt things that
> you sometimes need to set.
> 
> I'd love to be wrong on this, if anyone has a working, for all of the
> normal use cases, library like this, I'd love to see it.

Wouldn’t setsockopt map nicely to ioctl when there is a file system switch? The ioctl would switch into the network stack specific version naturally.

setsockopt(sd, SOL_SOCKET, SO_BROADCAST, &val, sizeof(int))

would become

ioctl(sd, SO_BROADCAST, &val)

More generally, the issue of meta-data and avoiding that ioctl becomes an intractable dumping ground is not easy to solve.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* [TUHS] Re: Re.: is networking different?
  2022-07-04 20:44 ` [TUHS] " Larry McVoy
  2022-07-04 21:31   ` Paul Ruizendaal via TUHS
@ 2022-07-04 21:33   ` Phil Budne
  1 sibling, 0 replies; 7+ messages in thread
From: Phil Budne @ 2022-07-04 21:33 UTC (permalink / raw)
  To: lm; +Cc: tuhs

Larry McVoy wrote:
> Decades ago, I tried to make a library that worked like this and it
> was problematic.  There are all sorts of setsockopt things that
> you sometimes need to set.
>
> I'd love to be wrong on this, if anyone has a working, for all of the
> normal use cases, library like this, I'd love to see it.

The DEC's TOPS-20 TCP/IP interface (coded on top of a set of new
system calls that implemented the BBN (original) TCP/IP interface for
TENEX/TOPS-20, since system calls could make system calls) was like
that.  BUT the TENEX/TOPS-20 system call to pass a pathname into the
system allowed "attributes" to be appended to paths as
";ATTR[:VALUE]"(*), which was used to determine whether it was an active
(connect) or passive (listen) open.

TCP was implemented as a logical device:
	TCP:[LOCAL_HOST][-LOCAL_PORT[#]].[FOREIGN_HOST][-FOREIGN_PORT][;A1..]

For details see:
	https://www.rfc-editor.org/ien/ien176.txt

And
	http://www.bitsavers.org/pdf/dec/pdp10/TOPS20/V7/JSYS_REFERENCE.MEM.txt
	(JSYS is the machine instruction used for system calls)

	A full set of attribute keywords at page 3-170 (search text document)
	and description of TCP: device as implemented in section 2.4.10

	NOTE!  The original text file undoubtedly had bare carriage return
	characters for overstrikes (bold and underscore).

A feature of this interface is that you can fully specify the
four-tuple of the connection when doing a passive open, which ISTR was
used by FTP (the client listened for a connection on the same local
address and port as the command connection, from the foreign address
and FTP-DATA port of the server, and the PORT command was not necessary.

An even more obscure implementation is in my port of the original
Bell Labs (Holmdel, that is) implementation of SNOBOL4, where I
implemented tcp connections (active only) as /tcp/HOSTNAME/SERVICE[/ATTR]...
where ATTR can be used to set various setsockopts:

	http://www.regressive.org/snobol4/csnobol4/curr/doc/snobol4io.1.html
	(search for tcp).

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [TUHS] Re: is networking different?
  2022-07-04 21:17 ` ron minnich
@ 2022-07-04 23:37   ` Paul Ruizendaal
  2022-07-05  3:02     ` John Cowan
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Ruizendaal @ 2022-07-04 23:37 UTC (permalink / raw)
  To: ron minnich; +Cc: The Eunuchs Hysterical Society

Thank you for sharing experiences on what worked and what did not. Much appreciated!

As I’m now too much on a tangent of what might have been versus what once was, I’ll follow up with a PM.

> On 4 Jul 2022, at 23:17, ron minnich <rminnich@gmail.com> wrote:
> 
> Something like what you mention: open(“/net/inet/any:80”, O_RDWR |
> O_STREAM | O_CREAT, 0600), is actually to be found in an RFC from
> around that time.
> 
> You can do that, but the 1980s tried it and it did not end well.
> What's it mean, for example, when you rename("/net/harv") to
> ("/net/google") -- close and reopen socket? (there's a Lost Talk from,
> I think, Rob, that addressed this very question)
> 
> While it has its flaws, https://9p.io/sys/doc/net/net.html in my view
> is the best example to date of how to get it right. Addresses are
> strings, just like paths -- well, they *are* paths in fact. Some of
> this path-like nature can be seen in the Go net package today.
> 
> Oh, and, as regards how the synthetic file system looks: you never,
> never, ever, put an address in the pathname. That's important.
> 
> Also consider that if you get it right, you can do all the network IO
> you want with cat and echo -- people have written telnet in Plan 9
> with those two commands. And, if you get it wrong, well -- you get
> socat.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [TUHS] Re: is networking different?
  2022-07-04 23:37   ` [TUHS] " Paul Ruizendaal
@ 2022-07-05  3:02     ` John Cowan
  0 siblings, 0 replies; 7+ messages in thread
From: John Cowan @ 2022-07-05  3:02 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: The Eunuchs Hysterical Society

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

> On 4 Jul 2022, at 23:17, ron minnich <rminnich@gmail.com> wrote:
>
> > You can do that, but the 1980s tried it and it did not end well.
> > What's it mean, for example, when you rename("/net/harv") to
> > ("/net/google") -- close and reopen socket? (there's a Lost Talk from,
> > I think, Rob, that addressed this very question)
>

Why shouldn't it just fail with EXDEV "No cross-device links"?

> Also consider that if you get it right, you can do all the network IO
> > you want with cat and echo -- people have written telnet in Plan 9
> > with those two commands.


Well, not really.  You need at least sed to convert 0xFF to 0xFF 0xFF on
the wire and back again, at least if you are talking to a conformant
implementation.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-07-05  3:04 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-04 20:09 [TUHS] Re.: is networking different? Paul Ruizendaal via TUHS
2022-07-04 20:44 ` [TUHS] " Larry McVoy
2022-07-04 21:31   ` Paul Ruizendaal via TUHS
2022-07-04 21:33   ` Phil Budne
2022-07-04 21:17 ` ron minnich
2022-07-04 23:37   ` [TUHS] " Paul Ruizendaal
2022-07-05  3:02     ` John Cowan

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).