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? Josh On Mon, Mar 31, 2008 at 10:42 AM, Joshua Stratton <[EMAIL PROTECTED]> wrote: > Hey, > > I did some reading up on the Plan9 design for their network hierarchy. I > think it's interesting. I wouldn't mind using it just so the layout would > be more commonplace (for those who may have used Plan9). I also like the > access to the interface statistics. Plan9, from what I've read, tries to > abstract the interfaces to look the same to the client, which seems a little > abstract to me if a client is going to control the data structures. It > might be the opposite of what the client wants. IMHO, I think the client > should be smart enough to choose the interface it wants as I don't think > that's a real hurdle for developers. > > I heard the deadline was extended by a week by someone on the GIMP > developer list and that it would be updated on Google's timeline for SoC. > However, I have not seen this change so I am assuming today is in fact the > last day. I am going to try to organize my last few ideas for the project > layout today before the closing period, but they'll be just ideas since it > seems several of the Hurd developers have provided a lot of different ideas > for the actual file structure they would like to see. I do like the Plan9 > approach, but I'm not sure if a "transparent" interface is really what the > Hurd group would want. > > Thanks, > Josh > > > On Sun, Mar 30, 2008 at 4:51 PM, <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > On Sat, Mar 29, 2008 at 05:04:48PM +0100, Carl Fredrik Hammar wrote: > > > > > > /ip/eth0/tcp/ /ip/eth0/udp/ /ip/eth1/tcp/ /ip/eth1/udp/ /ip/lo/tcp/ > > > > /ip/lo/udp/ /ip/tcp/ /ip/udp/ > > [...] > > > Shouldn't it be /eth0/ip/tcp/? I.e. with internet protocol is layered > > > over ethernet. > > > > Indeed, the more I think about it, the more I get convinced that you are > > right :-) > > > > There are some things to keep in mind though. When /ip is the top level, > > it can naturally serve as a master translator/multiplexer, managing the > > other nodes. With the device directories at the top, the question arises > > how to handle them... > > > > The simplest (but least elegant) approach would be simply to create > > static directories for each available device; and whenever an IP > > translator is attached, tell it the device explicetily. (settrans > > /net/eth0/ip /hurd/ip -d eth0) > > > > Another approach would be to have a rather dumb device translator, which > > tells the attached nodes what device to use, so it needn't be passed > > explicitely. > > > > Ideally, the device translator would actually sit between the kernel > > device and the clients, managing access... But I wouldn't consider that > > part of the IP stack task. (Actually someone was working on a BPF > > translator in the past, but it wasn't finished :-( ) > > > > A second question is how to handle listening on all available > > interfaces. (I think the socket interface allows for that?) A top-level > > ip translator could manage that in a natural way; with the devices at > > the top level, we need some additional facility to keep track of all > > available interfaces. It shouldn't be hard, but needs to be taken into > > account. > > > > > In any case, I'm not sure why you have chosen directories. Why not > > > just: eth0, eth1, ip0, ip1, tcp0, tcp1, tcp0+1 etc. where tcp0+1 works > > > like your /ip/tcp/? > > > > First of all, I hope you didn't mean to imply that the numbers in ip0 > > and tcp0 correspond to that in eth0... Because that would be plain wrong > > :-) lo for example has no number at all; while we could have both eth0 > > and ppp0 for example. So, if we want to enumerate the ip interfaces like > > that, the enumeration will be completely independant of the device > > names. > > > > But is it really useful to have such an enumeration at all? I think the > > socket interface doesn't use anything like that; interfaces are selected > > either by device name or by IP... (Correct me if I'm wrong.) And I don't > > see any reason to do different with the filesystem-based interface. > > > > The '+' syntax for listening on multiple devices looks interesting. I > > wonder though how useful it is. Does the socket interface provide a > > possibility for listening on multiple but not all devices? If not, is is > > useful to add such an ability?... > > > > In any case, we still need a way to specify the '*' case without listing > > all individual devices, I think. > > > > As for flattening the hierarchy, I'm very sceptical about that. True, it > > would simplify things: You could just have all the nodes in a normal > > directory for example, statically set up with passive translators; > > everything could be done with simple single-node translators. > > > > This is pretty ugly, though. It means that all the relations always have > > to be specified explicitely, e.g. "settrans /net/tcp0 /hurd/tcp > > /net/ip0". Also, it means a totally static setup. > > > > Instead of a normal directory, some kind of translator (multiplexer) > > could be used to manage all the nodes in /net. It could be more dynamic, > > and manage the associations between the nodes automatically. That would > > be very intransparent though; and it would destroy much of the > > decentralization and flexibility possible with the modular stack... > > > > With a directory tree on the other hand, the structure is expressed in a > > very natural, intuitive manner. But it's more work: First of all, it > > requires coming up with a good directory structure. Then the > > implementation is more complicated, as each layer has to export a > > directory with child nodes. And the setup gets more tricky: We don't > > have a normal directory anymore, where we could store all the nodes as > > passive translators; rather, the nodes are attached to virtual > > filesystems exported by the lower layers... > > > > One way would be for the virtual directories exported at each layer > > actually to allow storing ordinary passive translators. Of course, that > > would be very static again... > > > > Alternatively, each layer could launch the translators for the nodes it > > hosts, i.e. serve as a multiplexer. This is actually similar to hosting > > passive translators, except that the configuration (what to launch and > > when) would use some different, custom mechanism -- it would be more > > dynamic than passive translators, but less transparent. > > > > Yet another approach would be to leave the underlying translators out of > > the setup completely, and instead just set active translators for all > > nodes explicitely, using a script run when setting up the network > > interface. At least part of it probably could be even done by the > > clients themself upon demand -- the socket wrapper could do that > > transparently, while clients using the filesystem interface directly > > would have to do it explicitely. > > > > This setup question is a fundamental problem which we need to solve, not > > only for the network stack, but in general when we start using > > translators more extensively... > > > > Perhaps namespace-based translator selection can be useful here, once it > > is available: It would avoid explicitely setting translators > > alltogether, and instead one could for example just access > > /net/eth0/ip,,tcp to open a tcp connection on eth0. Problem with this > > approach is that it's not very transparent: Translated pseudo-nodes can > > be opened on demand, but don't show up in a directory listing... > > > > -antrik- > > > > > > >
