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

Caliban Tiresias Darklock caliban at darklock.com
Wed Mar 10 19:09:02 New Zealand Daylight Time 1999


On 07:48 PM 3/10/99 -0700, I personally witnessed Chris Gray jumping up to say:
>[Petri Virkkula:]
> >	I would probably go for multiple IP-addresses and multiple
> >	accepting servers. For example, hostname mud.dom.ain might
> >	have addresses 123.123.123.1-123.123.123.10 and ten processes,
> >	each of them listening only single address, not INADDR_ANY. I
> >	don't know how well this scheme would work though.
>
>The problem with that is that then the clients have to connect to one
>of those 10 ports. You might manage that if you have a special client
>that has a decent algorithm to balance the use, but if you rely on
>humans to do it, it won't work - most will use the first one all the
>time. There isn't any way to know which port is the least busy.

I've considered this sort of thing myself, and the only way I could think
of to do it would be to have a UDP connection on a port that checked the
load and told the client "Use port X" based on who was connected where. The
client would then make a TCP connect to the provided port. After
considering it, I thought it would probably be BETTER if your TCP
connection could send some notification to MOVE to some other port, and
then the client could connect to that other port and drop the old
connection based on existing load -- that way if processes 2 and 3 are
congested and you're on process 1, when process 1 fills up but 2 and 3 get
some disconnects, you could be shuffled to a lower load process. Basically,
under that model, you could tell the client where to connect every time and
then no matter WHAT port the human connects to he'll end up on the
best-case process.

Since I detest dedicated clients, I decided not to do this, but it was the
best I could come up with under the circumstances. You wouldn't need to do
the IP thing this way; just take connects, and when a process is overloaded
tell the client to go somewhere else. I would also have a protocol for
handshaking, where it goes something like this:

    connect port FOO
    >IAMASERVER
    <IAMACLIENT
    >OHNIFTY
    <WANNALOGIN
    >PORTBAR
    <THANKY
    >BYE
    disconnect
    connect port BAR
    >IAMASERVER
    <IAMACLIENT
    >OHNIFTY
    <WANNALOGIN
    >GORIGHTAHEAD
    [...]
    >HEYYOU
    <YOMANWHATYOUNEED
    >PORTBAZ
    <OKIE
    connect port BAZ
    >IAMASERVER
    <IAMACLIENT
    >OHNIFTY
    <FROMBAR
    >IKNOW
    [back on port BAR]
    <GOTIT
    >BYE
    disconnect BAR
    [etc.]
    
The obvious extension to this is to manage distributed machines. 

Um, that's about all for the moment. Maybe this will help someone ;)

-----
| Caliban Tiresias Darklock            caliban at darklock.com 
| Darklock Communications          http://www.darklock.com/ 
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D 
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=- 


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




More information about the MUD-Dev mailing list