It was a pleasure and quite educational to read your posting, Micah Stetson.
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.
Except the program wouldn't be any smaller than its UNIX equivalent. It
would simply be the same port forwarding that is present in NAT. Because
multiplexing a port requires either separate protocol stacks or a (complex)
endpoint translation scheme, i.e. NAT. (as I noted before aux/trampoline is
a transport layer proxy, by the way).
This last note aside, I think the issue of address translation has been
succinctly reviewed now (to my advantage, for I have learnt a lot along the
way :-). We can let it rest for a while and wait to see what Erik
Quanstrom's NAT implementation will look like.
--On Sunday, November 16, 2008 9:12 PM -0800 Micah Stetson
<[EMAIL PROTECTED]> wrote:
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
