Re: Networking design proposal

[Niels Möller]

Hisham Kotry <etsh_cucu@yahoo.com> writes:

> With two in-dependent ip-stacks you'll probably need
> to do more work on the socket interface, as each would
> act on every call to any function of the socket API.
> Besides, a stack started after another wouldn't know
> about the currently exsisting connections and would
> probably tear-down connections with RST or FIN packets
> (assuming TCP) to the sending host, while it shouldn't
> have, the case of having two seperate stacks
> implementing the same L3 protocol on the same NIC
> doesn't seem feasible to me, nor usefull.

The way I think about this is that you'd have to configure the two ip
stacks use diffrent ip-addresses. That's a natural restriction, and I
think it should make it reasonably easy to support parallel stacks on
the same hardware.

And I do think it's a useful feature. If you want to hack on a new
ip-stack, you have three options: Kill the old ip-stack while you're
testing the new one (annoying), or buy a sepratate network card so you
can give both stacks their own hardware to talk to (also annoying), or
design the ethernet device in such a way that several stacks can use
it in parallel.

As for applications, I think it's useful enough if you can make some
application use one of the stacks, and some aplications use the other.
Making an application use two stacks at once might be cool, but I
think that should be a library issue (in glibc or libsocket), the ip
stacks should not be required to cooperate.

> Well, smart NICs support hardware classification, and
> you could implement the hardware-type/mac-address
> registration in either software or hardware thru the
> same interface assuming device drivers will have some
> logic

Exactly, matching on harware tpy and mac is essential, the question is
if we need matching on packets contents as well (like the ip
destination address). And if so, we should have some generic interface
that isn't ip-specific.

> Doubt that, it'd be nicer if they just register
> themselves by providing a function that'd be called
> whenever the number they're interested in appears in
> the IP-protocol field. I don't see why a L4 transaltor
> would want to view/ignore any specific packet.

You may well be right.

> We shouldn't argue how L4 translators(or modules for
> that matter) would interact with L3 when we don't even
> have a decent interface for buffer handling.

That's kind-of orthogonal to the issues of how to divide
responsibilities up between layers and processes. For now I'm
imagining either using plain read and write, or passing around memory
pages, one page per packet or something like that. At least for a
start, one should keep things simple.

But I agree this discussion is somewhat sterile, it would really need
some real hacking to try out the ideas.

Regards,
/Niels