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

[Caliban Tiresias Darklock]

On 08:39 AM 3/11/99 -1000, I personally witnessed Nathan F Yospe jumping up
to say:
>On Wed, 10 Mar 1999, Caliban Tiresias Darklock wrote:
>
>Of course, I have none of your qualms about a dedicated
>client...

The primary reason I don't like dedicated clients is that I want to play
all my games from the same client. I play too many different kinds of games
to lock myself into some dedicated thing. I would consider it virtually
mandatory to release the protocol specs to the community, so a thoughtful
client author could add support for your server to his own client.
(Usually, this happens because a half-dozen persistent players bother him
to add it -- and it helps a lot when they can point him at a detailed
description of the implementation.)

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

An added bonus; since you have something monitoring the load, it can spawn
and kill port monitors when the load rises and falls. It might be helpful
to look at some FTP server source... instead of spawning connections on
unprivileged port random-X, you spawn listeners on it.

>The client should be able to make two or
>more connections... I'm still mulling on that.

Shouldn't be that tough, really. You just have two sockets; one for
negotiation, one for connection. When a request to reconn comes over a
connection socket, you state-change it to negotiation and use the other one
for connection. Ideally, the user never has to see anything happening. 

A potential problem, which you should cover somehow, is how to handle it
when server 1 says to connect to server 2 but server 2 is down. The player
should still have his connection to server 1, and be able to say that
server 2 is not responding without being bodily kicked off the server.
There's also the possibility that between "go here" and the client going
there, the other port's listener has somehow died or gotten overloaded. You
want to AVOID the possibility of something like "go here, no go there, no
go here, no there, CONNECTION REFUSED, NO CARRIER" (apologies for the
archaic terminology there, but it's quick and concise and nothing else is).
You need some sort of "cant do it" response which will allow the player to
stay right where he is and not get booted.

There are a lot of potential pitfalls, but you have to strike a balance
somewhere between covering problems and actually writing the code. It's
possible to think too much about the details, and not get around to
actually doing anything.

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

Exactly. I'm working on something similar to this myself... but I really
don't like the idea, so I'm not investing much in it. It's sort of a
grudging acknowledgement that people will want this, and if it's an
"obvious" extension, they'll bother me to do it. (See the half-dozen users
up there bothering the client author? Server authors tend to have a
half-THOUSAND users bothering them.)

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