On Mon, Mar 31, 2008 at 02:07:26PM -0600, Joshua Stratton wrote: > If anyone hasn't read up on how Plan9 runs their network stack, they have a > separate directory of each connection. An example in the paper is shown as > the following, > > # cd /net/tcp/2 <--- this is like the second TCP connection > # ls -l > ctl > data > listen > local > remote > status > > They use an interesting system to control their connections using ASCII > strings. For example changing the packet size would be as simple as "2400 > > ctl" would change the packet size to 2400 (some syntax to that effect). > They say this approach makes it compatible with remote applications that can > manipulate servers through a common interface. Supposedly all network > connections use this interface (TCP, UDP, LP). > > I think this approach would fit nicely into the Hurd's translator > architecture. However, I'm not sure if I like the directory structure they > use. I would think the network interface should be shown like > > /net/eth0/tcp/2 > > It might be worthwhile--but possible bad style?--to duplicate both > hierachies so on may browse the connections by device or generally. > > Any preferences/comments on this?
It's clearly a mistake to map the directory tree to the protocols stack. The TCP implementation is a global layer, it handles network interfaces internally and must not be bound to any interface (ask yourself how to implement INADDR_ANY, or IPv4 capable IPv6 sockets). In addition, separating the network and transport layers implies several problems. The most obvious one concerns performance. The Mach IPC subsystem provides nice virtual copy support, but this facility creates an important overhead that severely impacts high speed connections. Carefully shared memory between the servers may help though. I'd rather suggest having network and transport implementations as shared object modules. This will help you define the complex interface between these components. Keep in mind that there are a lot of protocol specific interactions (e.g. the ICMP implementation interacts with IP, UDP and TCP to handle redirects, path MTU discovery, closed ports, etc...). Having a monolithic entity for IPv4/v6 and TCP/UDP/ICMP (at least) should help you solve interface and integration probems (of course, once the interface is OK, you can try moving the implementations in separate translators and experiment, but this is a (very?) long term step. -- Richard Braun
signature.asc
Description: Digital signature
