Hurdish TCP stack (was: updated proposal)

[olafBuddenhagen]

Hi,

On Sat, Mar 29, 2008 at 05:04:48PM +0100, Carl Fredrik Hammar wrote:

> > /ip/eth0/tcp/ /ip/eth0/udp/ /ip/eth1/tcp/ /ip/eth1/udp/ /ip/lo/tcp/
> > /ip/lo/udp/ /ip/tcp/ /ip/udp/
[...]
> Shouldn't it be /eth0/ip/tcp/?  I.e. with internet protocol is layered
> over ethernet.

Indeed, the more I think about it, the more I get convinced that you are
right :-)

There are some things to keep in mind though. When /ip is the top level,
it can naturally serve as a master translator/multiplexer, managing the
other nodes. With the device directories at the top, the question arises
how to handle them...

The simplest (but least elegant) approach would be simply to create
static directories for each available device; and whenever an IP
translator is attached, tell it the device explicetily. (settrans
/net/eth0/ip /hurd/ip -d eth0)

Another approach would be to have a rather dumb device translator, which
tells the attached nodes what device to use, so it needn't be passed
explicitely.

Ideally, the device translator would actually sit between the kernel
device and the clients, managing access... But I wouldn't consider that
part of the IP stack task. (Actually someone was working on a BPF
translator in the past, but it wasn't finished :-( )

A second question is how to handle listening on all available
interfaces. (I think the socket interface allows for that?) A top-level
ip translator could manage that in a natural way; with the devices at
the top level, we need some additional facility to keep track of all
available interfaces. It shouldn't be hard, but needs to be taken into
account.

> In any case, I'm not sure why you have chosen directories.  Why not
> just: eth0, eth1, ip0, ip1, tcp0, tcp1, tcp0+1 etc. where tcp0+1 works
> like your /ip/tcp/?

First of all, I hope you didn't mean to imply that the numbers in ip0
and tcp0 correspond to that in eth0... Because that would be plain wrong
:-) lo for example has no number at all; while we could have both eth0
and ppp0 for example. So, if we want to enumerate the ip interfaces like
that, the enumeration will be completely independant of the device
names.

But is it really useful to have such an enumeration at all? I think the
socket interface doesn't use anything like that; interfaces are selected
either by device name or by IP... (Correct me if I'm wrong.) And I don't
see any reason to do different with the filesystem-based interface.

The '+' syntax for listening on multiple devices looks interesting. I
wonder though how useful it is. Does the socket interface provide a
possibility for listening on multiple but not all devices? If not, is is
useful to add such an ability?...

In any case, we still need a way to specify the '*' case without listing
all individual devices, I think.

As for flattening the hierarchy, I'm very sceptical about that. True, it
would simplify things: You could just have all the nodes in a normal
directory for example, statically set up with passive translators;
everything could be done with simple single-node translators.

This is pretty ugly, though. It means that all the relations always have
to be specified explicitely, e.g. "settrans /net/tcp0 /hurd/tcp
/net/ip0". Also, it means a totally static setup.

Instead of a normal directory, some kind of translator (multiplexer)
could be used to manage all the nodes in /net. It could be more dynamic,
and manage the associations between the nodes automatically. That would
be very intransparent though; and it would destroy much of the
decentralization and flexibility possible with the modular stack...

With a directory tree on the other hand, the structure is expressed in a
very natural, intuitive manner. But it's more work: First of all, it
requires coming up with a good directory structure. Then the
implementation is more complicated, as each layer has to export a
directory with child nodes. And the setup gets more tricky: We don't
have a normal directory anymore, where we could store all the nodes as
passive translators; rather, the nodes are attached to virtual
filesystems exported by the lower layers...

One way would be for the virtual directories exported at each layer
actually to allow storing ordinary passive translators. Of course, that
would be very static again...

Alternatively, each layer could launch the translators for the nodes it
hosts, i.e. serve as a multiplexer. This is actually similar to hosting
passive translators, except that the configuration (what to launch and
when) would use some different, custom mechanism -- it would be more
dynamic than passive translators, but less transparent.

Yet another approach would be to leave the underlying translators out of
the setup completely, and instead just set active translators for all
nodes explicitely, using a script run when setting up the network
interface. At least part of it probably could be even done by the
clients themself upon demand -- the socket wrapper could do that
transparently, while clients using the filesystem interface directly
would have to do it explicitely.

This setup question is a fundamental problem which we need to solve, not
only for the network stack, but in general when we start using
translators more extensively...

Perhaps namespace-based translator selection can be useful here, once it
is available: It would avoid explicitely setting translators
alltogether, and instead one could for example just access
/net/eth0/ip,,tcp to open a tcp connection on eth0. Problem with this
approach is that it's not very transparent: Translated pseudo-nodes can
be opened on demand, but don't show up in a directory listing...

-antrik-