Igor Khavkine <[EMAIL PROTECTED]> writes: > Well, that's what I was asking about. Maybe a better idea would be to make > pfinet support a general tunneling interface that gives control of the > underlying protocol to a userspace daemon like ppp, slip, plip or whatever > else one can run in userspace.
Note that pfinet is just as "userspace" as any other daemon. I suppose you really mean dividing up the work between several daemons? I would think that the first step in splitting pfinet into several processes is to think about the interfaces between the processes, and the resposibilities of each. (Of course, the result of that thinking might also be that the whole division thing was a bad idea). One division could be: pfinet keeping track of ip packets, addresses, sockets (including all tcp processing, etc) and interfaces, and possibly some routing info. ppp and eth sending and receiving ip packets using the appropriate link-layer mechanisms > Or another idea would be to setup each interface as a translator > somewhere under /servers/socket/2/. My first guess is no. Address family (the "2"-part of /servers/socket/2) is somewhat independent of the link-level transmission mechanism (ppp or ethernet). For instance, consider using a single ethernet card for both ipv4 and ipv6; in this case I suspect that you want a single process doing all of the ethernet stuff. But that also depends on what ethernet device drivers look like, perhaps it is no problem to have one ipv4 and one ipv6 process talking using the same device? Getting received ethernet packets to the right process seems to be more difficult than having several processes sending packets. Bottom line: I think it would be a very valuable contribution to look carefully on the network stuff architecture, try to sort it out, and write up your conclusions. /Niels
