Re: New network implementation proposal [was: Re: ipv6 on hurd]

[Niels Möller]

Olivier Péningault <peningault@free.fr> writes:

> - A translator per physical device, wich will present the upper side of
> a layer 2 protocol (ex: ethernet protocol over an ethernet card, ppp
> over a serial port, ...)

I think this is the right way, no matter how the servers above this
are designed. As for separation between user and kernel level, I don't
know where to draw the line, but on least on mach it should probably
be some kernel code that fiddles the registers on the ethernet card.

I think one goal is to support several pfinets, you want to be able to
run the old pfinet in parallell while hacking on the new networking
code. Adapting the old pfinet to the new ethernet device should also
be a simple sanity check of its design.

> (Then I don't want to do like in pfinet. Protocol code must not be part
> of a big translator, while replacing one protocol is too hard. Here is
> my idea:)

You need one piece of code that links between glibc and your ip
interfaces, and that also performs packetforwarding, source and
destination address selection, and such stuff. That code should be
installed as the translator for /servers/socket/2.

If you want to do ipv6 in such a way that an ipv6 socket can accept
ipv4 connections, you also need some code that is aware of both ipv4
and ipv6. And my feeling is that it shouldn't be glibc's
responsibility.

> /servers/net/protocols/(ip4|ip6|icmp|arp|x25|tcp|udp|sctp|.......)

Hmm. You could do something like that, but I don't think it makes
sense to mix level 3,4 and 2 protocols like that. For instance, the
only two pieces of code that need to know about arp should be (i) the
code that implements ip-over-ethernet, and (ii) the arp program.

In any case, I think for a start you should keep tcp and udp in the ip
server. You want to minimize the number of rpc calls involved when a
program calls send() until the packet is out on the wire. Keep it
simple.

> - Finally, another translator (one for the whole system) named hurd-net,
> that will be the center of the stack. It will be a multi-threaded,
> non-replaceable, updatable by users, interface between a)users b)layer
> 3+ translators and c)layer 2 translators.
> It will be stored in /servers/net/hurd-net

What will live on /servers/socket/2 then? That's the rendezvous point
used by glibc.

> Users will be able to add and use their own logical interfaces
> in hurd-net.

I'm not sure that makes sense. You shouldn't be able to manipulate the
other user's networking, and  don't think you want security (like
keeping track of ownership of sockets and interfaces) in
hurd-net/pfinet.

If a user wants to hack his own networking stacks, it makes more sense
to me that he runs his own pfinet, delegating some interfaces to the
other pfinet.

Hmm, that brings me to some other thing: Even if I don't quite buy the
idea of making each protocol it's own process, I think it would make a
lot of sense to define an rpc-interface representing one ip interface.
pfinet could populate a directory with nodes representing available
interfaces. That way, a parallel pfinet can send packets through
interfaces in the system's pfinet.

> I would like people here to discuss about it, and then (but not before
> two monthes) I'll begin to implement it.

Don't wait for too long for discussion.

I think you can start hacking away on the level-two
translators/devices right away. To get useful comments on the rest of
the design, you should also start by specifying the interfaces you
need. On one end, you have the interface between glibc and pfinet (the
/servers/socket/*-translators), which you need to understand (I
haven't looked at it myself so I have no idea what it looks like), on
the other you have the interface provided by en ethernet or ppp
translator.

Another idea, which might just make sense: Abandon pfinet. Abandon the
central networking server. Have only interfaces, living as nodes in
the filesystem, on which one can read and write packet. Put the
networking code *in the user process*.

I.e. when I call socket(), connect() to create a tcp connection, I
call some function in -lsocket that starts a thread does the tcp
handling as a part of my own process.

/Niels