AW: [Arianne-general] A few things to consider.

[<Min...@t-...>]

> But those problems exist using zones or portals between 
> servers as well. The underlying principle remains the same. A 
> player migrates from one server to another. That still 
> entails a good deal of intra-server communication and a room 
> or zone with tons of clients can still get into a situation 
> where the server's TCP stack is queuing recv's faster than 
> the server can actually receive them.

Well.. no and sort of... a player migration wont be something that takes
a lot of overhead
because there will be only one try and then the player has to redo his
request.

A player migration will in size be about the same thing than a full
perception on game start.
Its not too much, but could in XML be of some size after all.

Lets say... a player with his backpack with 100 objects in it. Thats
about 100 objects with maybe
10 attributes each. thats 1000 attribs, that in XML maybe 1000 x 20
byte, thats 20K bytes... I think....

Anyway.. I am not good in math.. but its too big to do it with XML in
any case. Take 100 players that switch
servers at one time and you go over board with that XML inter server
communication.

I am still trying to convince Miguel to drop that XML network packet
idea for that same reason,
but I am quite sure once the server is really done we will drop XML
packets in favor of packed raw data... :)
(Miguel doesnt know yet though :P )

To the TCP stack: It doesnt matter, that thing you talking about happens
to every server. Its always possible to
swamp it and slow it down. But that is no reason to not use portals...
portals help with that issue, because a zone
can be made as small as you like it to be... a city would be a SMALL
zone, an empty desert a large one.

> Imagine a town room with a hundred or so players milling 
> around in the streets. You're server is going to be working 
> pretty damn hard calculating and pushing delta observations, 
> taking and processing incoming orders and actually playing 
> the game. On a lower end system, you're going to start 
> pushing the threshold regardless of inter-server exchanges. 
> Walking from a shop (on a different server) back to the main 
> street (server in question), you're avatar's migration is 
> still going to be queued - first by the stack, then by the server.

Yes of course but now think it has to be real time like with invisible
server boundaries... DOH!
The server would need to send the request a few times to get it
across.... like polling.
And as we all know, polling is bad.. polling is evil... lol.

With Potals there is no polling. Players wont be able to swamp a server
to the degree that it cant accept anymore
migrations. Cause they got to click some icons to make the exit happen.

The only reason then would be if there are REALLY too many people
playing in that zone, and will never happen...
Just throw them somewhere else, and dont allow more entries into the
zone... there is no way a zone can get swamped with players,
because you just stop letting them in.. hehehe....

Also I got some nice ideas actually about the issue of having too many
players in some zone.... ;)
You can gently force them off the zone with some cool quest script.
Hehehe... (something that UO never had... cool quest scripts :P)

> Also, since it still uses some kind of migration, there's 
> still a possibility that characters can be lost (with a bad 
> implementation) and/or duplicated (with an even worse implementation).

No there wont be any possibility of anything getting lost, be assured...
;)

> I think the one thing you can say for certain is that using a 
> continuous map, you're probably going to end up with more 
> inter-server communications, and client-server as it resolves 
> map boundaries. A little more network overhead, but solveable i think.

Yes solvable but stupid... solvable to a degree that makes it work, but
not solvable to make it happen under
all circumstances. We cant guarantee that it works, so we better dont
implement it.

> Anyway, it doesn't really matter. I've never been so attached 
> to the continuous map idea. It just makes the world a little 
> too big and a little too tedious to walk across :)
> 
> andy