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

[Olivier Péningault]

le jeu 24-10-2002 à 21:49, Niels Möller a écrit :
> 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.
I spoke (not clearly) about it: there will ba a translator wich
implements pfinet interfaces, and redirects calls to the new code in a
good way. It will avoid porting programs and library urgently. But it
will have do disapear one day...

> 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.
ipv4 and ipv6 can run separatly.

> 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.
ip-arp-icmp are a problem, because this layer is divided in three
protocols, each one has different goals. hurd-net will know how to
manage that.
But be carefull, protocols translators don't know the others one. The
only translator of the stack who knows everybody is hurd-net.
And we'll can have differences for the interfaces for the different
layers; each layer has specific things to do, they all transmit datas
(this could be a generic interface) but some of them have specific tasks
(this could be a per-layer interface). per-layer interfaces will make
ip-arp-icmp work "good" together.

> 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.
I agree; there will be (too) many rpcs, but I wouldn't like to do
something ala pfinet, ie: all protocol mixed all together...

> What will live on /servers/socket/2 then? That's the rendezvous point
> used by glibc.
Yes, it can. But maybe it is the translator which will tranform pfinet
calls to hurd-net calls that will be there, and libc, ... will be
adapted to the new interface step by step.

> 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.
Ok, i wasn't clear. Users can create interfaces, but they are only used
and seen by them. Users can replace default interfaces, and use them, so
when hurd-net will check interfaces and verify which one to use, user's
rights will be an important information (but also the logical describer
of the interface in hurd-net). When a user creates a new interface,
rights are set to this user's rights.
hurd-net can't be replaced, because it will contain important datas,
such as addresses. The only thing users can do is multiplexing
protocols, by setting up new network interfaces.

> 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.
Yes, but you need to centralize some datas, running many pfinet will not
garantee that data is in sync in every pfinet (think about addresses,
you must have a central repository, because you can't change them too
easilly. hurd-net will have threads to implement logical-physical
interfaces, but also thread(s) to answer requests about important datas
stored in the net stack.).

> 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.
That's the way hurd-net works. We have default interfaces, with one
thread per interface. Each time a new interface is created,
- it exists, we update rights.
- it does not exist, we create a new thread, which will autoconfigure
itself (hum !! It is hard to explain, maybe I should write a paper with
good explainations for these kind of ideas...).

> Don't wait for too long for discussion.
This is not for discussion only. I have many things to do, but I really
will have time in the beginning of 2003. Before that, I will not do much
work.... :(
> 
> 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.
That's right. Ok.

> 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.
I see what you mean. For the layer 3+ translators, at first I thought
that it could be libraries, but concepts of the hurd are differents. How
can users replace a library if they want ? Translators are better for
this kind of features.

olivier