This is just a guess at their implmentation but....

To handle large amounts of players they need *many* servers. Each with fast internet connections.

I wouldn''t be surprised if there''s more than 10 servers per world. Again it all depends on the hardware their running for servers. If they''re using Sun boxes they won''t need as many servers as if they were running on intel boxes.

My guess is that each zone is a seperate process, and many zones exist on a single server. This way they can connect zones no matter where they''re running.

When you "Zone" what''s probably happening is that the current process that handling your previous zone is communicating with another process that may or may not be on the same machine to set up the transfer of your character.

Obviously they must a centralized server that stores your character state/details which is updated when you see "saving your character...". This is definetly a *HUGE* Sun box running an Oracle database with *many* processors, and gigs of RAM.

I kinda of like their idea of zoning, as the design enables scalability easily. (Just add a new server!)

Even games that claim seemless worlds (i.e. UO) implment a Zoning design. UO claims to be seemless, but in reality each world is subdived into 4 worlds handled by different servers. You can notice a slight lag when crossing one of these "server boundries" because you are "zoning".

Again I don''t know if I''m right but I think this is close to their actual design. (Comments?)

hope this helps...

As I recall ALL of EQ servers are located in a centralized location (although probably different backbones), and I agree that a login server must be able to handle the requests, BUT...

A login server only has to deal with one thing: Logging in the players.

Which is *extremly* simple. Think of a web server that can handle 10,000 sim. requests. This server doens't have to have any fancy hardware, a P3 600 Mhz machine is easily capable of this feat, (with a sufficient connection).

Here's the login pseudo code:

while (login_server_is_running)
{
player = waitforconnection()
spawn thread to handle login(player)

}

These requests are really small, and so is the connection overhead, basically connection between this server start/die very quickly (Their desired server handles the connection immediately after account validation)

Take a look at any heavy traffic web site, imaging your server only has to handle small user/password packets, not image transfers etc.

I know most game developer machines could handle EQ's login requests with a sufficient backbone connection.




Edited by - Darrell on August 6, 2000 7:31:37 PM