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

[Nathan F Yospe]

On Wed, 10 Mar 1999, Caliban Tiresias Darklock wrote:

: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

:>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:

Hey, thanks! I *love* it. I'd not even considered the problem myself... there
was no need to with the current state of unreadiness... but in hindsight,
this is brilliant. Of course, I have none of your qualms about a dedicated
client...

Perhaps a few minor alterations:

In the preferences, a default server and port... perhaps linked to the game,
with a reset default configuration for a host-server that provides a list of
known games that support the client and sets the default to a chosen game; I
can always make that more robust. The client should be able to make two or
more connections... I'm still mulling on that.

    {connector 1}

    connect [<server_ip1>|<server_dn1>] <port1>
    >SERV ID=<id1>
    <CONREQ
    >TRANS [<server_ip2>] <port2>
    <TRYING

    {connector 2}

    connect [<server_ip2>] <port2>
    >SERV ID=<id2>
    <CONREQ
    >OK CLIENT ID=<id3>
    <CONFIRM SERV ID=<id2> CLIENT ID=<id3>

    {connector 1}

    <SUCCESS
    >OK BYE

    {connector 2}

    . . .

This should help with error handling and process management.

:The obvious extension to this is to manage distributed machines. 

Yes; and possibly to use this to pass clients to remote servers when
their character has been transfered as well. (I use a "geographical"
mapping of location to server-space. This would work quite well for
me.)

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

--

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
University of Hawaii at Manoa, Dept of Physics, second year senior (joy)
(On Call) Associate Algorithm Developer, Textron Systems Corp, Maui Ops.
yospe#hawaii.edu http://www2.hawaii.edu/~yospe Non commercial email only



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