[MUD-Dev] Re: Multi-Server games

[Vadim Tkachenko]

Ben Greear wrote:
> 
> On Mon, 29 Jun 1998, Vadim Tkachenko wrote:

[skipped]

> > OK, you have the multiple servers and distributed world now, but where
> > do you connect to next time, after you've crossed the world borders?
> >
> > There are at least two possible answers:
> >
> > - Keep the entry point the same and just route the requests to the
> > remote world, thus increasing overhead
> > - Change the entry point, complicating the client (which may not allow
> > it at all, like applet)
> >
> > Any comments?
> 
> I agree, these are two tricky problems.  I'm planning on letting
> the client log onto the server which holds the player.  This information
> can be querried among the servers, so hitting any client should be
> able to point you to the right one.  If I end up using an applet, I'll
> have a httpd server on every game server, with identical jar files etc.
>
> An HTML query of some sorth (cgi?) could generate a page containing the
> correct link to the player's server.

That's exactly why I was asking a question about a LDAP server about a
week ago. I think, it would be wise to hold all the player information
somewhere on the dedicated server (we're coming at the idea of a domain
controller, with an implication of having a backup one and a protocol
which will be able to resolve the right server using broadcasts) and
make all the world servers ask this server[s] about the player info.

Also, the idea of a load balancing comes to my mind...

> An even nastier problem lies in smooth transition between two servers.
> 
> This will be virtually impossible with an applet.

Unless you have a really STUPID redirector service at the server side,
which just pipes the stream to the right server.

WORD OF WARNING: Often the applet/servlet combination appears to be a
logical solution. It is not. I mentioned before that I've implemented a
thing called 'reusable client/server multiprotocol framework', and one
of the components there is a protocol adaptor. So, servlets suck in
comparison to plain sockets (there was a test case ran on both servlet
and socket protocol adaptors): performance penalty is HUGE - at least
100:1, if I remember the results right. Benchmark classes are available
also, on request.

Bottomline: servlets aren't for advanced client. They're MUCH better
than CGI, though.

Side effect: It may be obvious for you guys around here, but was not to
my cow-orkers, that the servlet runs within the usual JVM. Correct me if
it's not right for Windows, but on UNIX it's possible to use the servlet
engine as a booster for another service which accepts the socket
connections and then reconnect to it.

Another side effect: ServletExec (TM?) spawns multiple copies of the
JVM, which breaks the servlet-to-servlet communication which is supposed
to be there. Cure: Apache.

> I'll probably just route the messages through the connecting server to
> any new server, remaining at a max of one hop of course.

Nod

> For local servers running on a faster ethernet connection, that
> shouldn't be too bad.  For largly disparate servers, bandwidth wise,
> another solution would have to be thought up...

I see the situation with multiple servers as for the commercial
enterprise only, so the case you've just described shouldn't be a
problem.

> Ben

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are