[MUD-Dev] How to support 1000+ simultaneous connections, and some philosophy.

[Chris Gray]

[Petri Virkkula:]

 >	As others have pointed out there would not be multiple ports,
 >	but multiple addresses with a single port number. The
 >	addresses would then be given out eg. in round-robin
 >	order. This is how many www-sites balances load between
 >	multiple machines (my suggestion would distribute the load
 >	between multiple processes, not machines).

Doesn't that require a custom DNS, so that it does hand out the IP's
in round-robin fashion? What about DNS's that cache associations?

 >	Make the connection server accept eg. 1000 connections (and
 >	serve them all). After that the server can fork(). The new
 >	child would then close the main socket that is being listened
 >	and only serve its 1000 clients. As soon as all the 1000
 >	clients have closed their connections just exit the child. At
 >	the same time the parent process closes all the client sockets
 >	and start again collect a new set of 1000 clients.
 >
 >	The above method might result in multiple processes, each of them
 >	handling just few clients. But the system might work fairly
 >	well, but that is difficult to say without testing.

Yep. In the worst case, you end up with a process per client! Perhaps
maintain some kind of central control, and when a process has a goodly
amount of excess client capacity, tell it to re-open the main socket,
so as to accept more connections. The flaw with any scheme that tries
to move the main connection point around like that is that there are
small windows when the IP/port is not present, and clients hitting
that window will get a failed connection. With a custom client you
can retry, however (but then, lots of solutions work with a custom client).


An earlier post talked about moving client connections around, using
a custom client able to do that. One thing to watch out for there is
that you have to mark a client as moving before you start moving it.
That way you queue up all outgoing stuff to it while it is in motion,
so that you don't end up having to bounce them all around.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev