Neal H Walfield <[EMAIL PROTECTED]> writes: > >> 1. Has anybody thought about partial delegation of networking? Does > >> that make sense at all? > > > > I have some vague ideas. I think it does make sense, but making it > > work seems hard. But if someone prods me, then I can describe my > > vague ideas. > > Prod, prod.
There are many different ways to split things up. First, we could right now arrange to run multiple IP stacks on the same machine, with different addresses, by: * disabling the assumption in the routing code that every packet got to the local host deliberately, and throwing out ones aiming at different IP addresses; * having the packet filters select only those packets which are either ARP or destined for a specific IP address; * come up with a way to get packets from one IP address to the other [since the ethernet driver might well not do the implied copy, and ethernet hardware does not allow you to receive the packet you send]--that is, a kind of meta-loopback device. A second idea is to enable different programs for different IP protocol layers. To make that work, I think you need a shared library that knows all about how to send IP datagrams, and uses some kind of shared segment holding routing information, and then packet filters can get incoming packets to the right layer. Different ethernet protocol types are very easy to make work, of course. The second idea can be done at higher layers as well: completely different TCP implementations could key depending on which remote port. Doing this would require a way to tell the generic TCP to ignore the packets that are going to a specialized TCP, so that it doesn't erroneously reset the connections.
