"Robert G. Brown" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
