>> That isn't happening. All we have is one TCP connection and one small >> program exporting file service. > > I see. But then, is it the "small program exporting file service" that does > the multiplexing? I mean, if two machines import a gateway's /net and both > run HTTP servers binding to and listening on *:80 what takes care of which > packet belongs to which HTTP server?
The Plan 9 kernel doesn't do load balancing like that. (Why should it?) To do it in Plan 9, you'd write a small program that listened on a particular address and multiplexed connections to a list of other addresses. It wouldn't be hard -- aux/trampoline is halfway there. I think you're still thinking of importing /net in terms of NAT. It can be used to solve some of the same problems, but it isn't the same at all. Exportfs (the small program above) doesn't know that it's exporting a network stack or any kind of "special" files because the files in /net aren't special. The network stack doesn't know it's being used by a different computer -- it just sees exportfs reading and writing its files. The HTTP server doesn't know it's using somebody else's network stack, it's just reading and writing files in /net that it expects to work a certain way. The only component that knows there's a network stack being forwarded from one machine to another is the person at the controls. This is nothing like NAT. No packets are rewritten, and no code exists solely to support one computer using another's network stack. So FTP and other protocols that frustrate NAT work without special treatment. The same principal obviates the need for port forwarding. (In Plan 9 networks, that is.) Micah
