[JDEV] scaling a single server?

[Donn Cave]

Quoth "Dave Smith" <dsmith at ai.uwf.edu>:
|> I don't know what the limitation of Linux for the sockets are, but the
|> absolute limitation is 64k since the port value is 2 bytes wide. So, with
|> TCP/IP you cannot have more then 64k connections (this is a theoretical
|> maximum, in reality more limitations apply) even if you have a
|> server-machine that can handle the load.
|
| Err..this isn't true (to the best of my knowledge). There are only 65536
| ports available for *listening* on most BSD socket impls. When a TCP
| connection arrives it doesn't stay on the port it initally connects on.
| Instead, the IP stack does some magic and the connection is diverted to a
| "pseudo-port" (if you will) that handles the connection from then on. Thus,
| you can have many more actualy socket connections than port numbers
| (assuming your kernel is setup to handle it). At least, this is my
| understanding of the matter... :)

Does this mean that if two separate clients used getsockname() to look
at their connections, they could turn out to be on the same port (from
struct sockaddr_in sin_port)?  That would be pretty surprising to me!
If not ... sin_port is typically 16 bits.

| > any messages. You may end up with a server that processes nearly no data,
| > but all its resources are exhausted because of the users connected.
| >
| > I strongly recommend connectionless protocols and UDP!
|
| Point taken. However, I would remind you again that the point of jabber is
| simple clients. :) Right now it's fairly trivial to write a jabber client.
| If every author had to add in flow-control and reliable delivery, client
| complexity would be significantly increased.

I don't know, it might not be all that bad, assuming some common code.
But if the issue is whether the system architecture allows 64K
connections, I think we're probably kidding ourselves, the practical
limit of a TCP service host is less than 64K.  This is a function
of the implementation, though, mbufs and that sort of thing, and
I have no idea but it would surprise me if it's not at least one
order of magnitude less for the average UNIX platform.

This doesn't stop protocols from being implemented in TCP when it's
appropriate.  There are good things about it, such as an immediate
notification on loss of connection tells you that the client has
gone away.  I would be more worried about inconveniently persistent
connections, either aborted connections in CLOSE_WAIT or other
unfortunate state, or just lack of a reasonable idle connection
timeout policy.  Put it in the documentation: client software
MUST be able to cope with a server disconnect!

	Donn Cave, donn at u.washington.edu