[Beowulf] automount on high ports

[Perry E. Metzger]

"Robert G. Brown" <rgb at phy.duke.edu> writes:
> On Wed, 2 Jul 2008, Carsten Aulbert wrote:
>> Which corresponds exactly to the maximum achievable mounts of 358 right
>> now. Besides, I'm far from being an expert on TCP/IP, but is it possible
>> for a local process to bind to a port which is already in use but to
>> another host? I don't think so, but may be wrong.
>
> AFAIK, no they don't.  The way TCP daemons that listen on a
> well-known/privileged port work is that they accept a connection on that
> port, then fork a connection on a higher unprivileged (>1023) port on
> both ends so that the daemon can listen once again.

Try netstat on a heavily loaded SMTP box. You'll see all these
connections from some random foreign port to port 25 locally -- lots
of connections to port 25 at the same time.

You don't switch to a different port number after the connection comes
in, you stay on it. You can in theory talk to up to (nearly) 2^48
different foreign host/port combos off of local port 25, because every
remote host/remote port pair makes for a different 4-tuple.

> Many daemons have a limit that can be set on the number of
> simultaneous connections they can manage.

That's a resource issue, not a TCP architecture issue per se. You
might not have enough memory, CPU, etc. to handle more than a certain
number of connections.

By the way, you can now design daemons to handle tens of thousands of
simultaneous connections with clean event driven design on a modern
multiprocessor with plenty of memory. This is way off topic, though.

> However, this is for TCP ports that maintain a persistent connection.
> UDP ports are "connectionless" and hence somewhat different.

I'm assuming they're doing NFS over TCP. If they're using UDP, things
are somewhat different because of the existence of "connectionless"
UDP. However, they *should* use TCP for performance. (I know people
used to claim the opposite, but it turns out you really want TCP so
you get proper congestion control.)

Perry
-- 
Perry E. Metzger		perry at piermont.com