Page 1 of 1

Client <-> Server communication

Posted: 29 Sep 2005 19:45
by uzurpator
The client and server obviously need to communicate. So we need to develop a protocol that will ensure low bandwidith usage and smooth gameplay.

I propose something like this:

Data is divided in three classes
- static - data that is very seldom changed - like terrain information
- dynamic - data that changes from frame to frame - like vehicle positions
- periodic - data that is changed regularly every X frames - like vehicle brakedowns (eg - we check for brakedowns every X frames) or economy changes.

Now - create an 8 byte frame counter, on each frame we increase it.

Each example of static data contains an 8 byte field showing when this data was last changed (frame number). Also it contains a field showing when each of the clients last accesed this data.

If last access > last change - the server will send "you have up to date" response. If last access <= last change the server will send the data.

Obviously we need to clauster the data in question as keeping the counter for each - say - map vertex - will eat memory like donuts.

For periodic data the client will ask for it when it is in its viewport and the "change" time has come. (for some info - when change period is long enough - we can treat this a static data)

The dynamic data will require an update on each snapshot for each of the clients.

There will be two modes for the client:

FULL - the client will slowly build a copy of server data in its own memory space. This will cut the requirements for bandwidth (potentially - when the client is hopping left and right - quite notably), but increase memory needs.

CACHE - the client will keep a cache of X last accessed objects and request always up-to-date information. This is mode for the LAN games, LOCALHOST games and places where there are memory constraints, but no bandwidth constraints.

Waddya think?

Re: Client <-> Server communication

Posted: 30 Sep 2005 12:10
by fujitsu
uzurpator wrote:The client and server obviously need to communicate. So we need to develop a protocol that will ensure low bandwidith usage and smooth gameplay.

I propose something like this:

Data is divided in three classes
- static - data that is very seldom changed - like terrain information
- dynamic - data that changes from frame to frame - like vehicle positions
- periodic - data that is changed regularly every X frames - like vehicle brakedowns (eg - we check for brakedowns every X frames) or economy changes.

Now - create an 8 byte frame counter, on each frame we increase it.

Each example of static data contains an 8 byte field showing when this data was last changed (frame number). Also it contains a field showing when each of the clients last accesed this data.

If last access > last change - the server will send "you have up to date" response. If last access <= last change the server will send the data.

Obviously we need to clauster the data in question as keeping the counter for each - say - map vertex - will eat memory like donuts.

For periodic data the client will ask for it when it is in its viewport and the "change" time has come. (for some info - when change period is long enough - we can treat this a static data)

The dynamic data will require an update on each snapshot for each of the clients.

There will be two modes for the client:

FULL - the client will slowly build a copy of server data in its own memory space. This will cut the requirements for bandwidth (potentially - when the client is hopping left and right - quite notably), but increase memory needs.

CACHE - the client will keep a cache of X last accessed objects and request always up-to-date information. This is mode for the LAN games, LOCALHOST games and places where there are memory constraints, but no bandwidth constraints.

Waddya think?
I think it >= good. But as you say, we need to cluster the data such that it doesn't eat memory like... well... something that eats a lot of memory in a very short time... That is really the only issue, except perhaps the memory used by 'FULL,' which can perhaps be solved by swapping to/from the HDD.

William.

Posted: 26 Oct 2005 16:06
by PJayTycy
For static data (like terrain)

can't we use an event-based system?

Like:

"event 487 : vertex 56,70 new height : 298" ?


Ofcourse we need to make sure everything is ok on all clients, so we could calculate a checksum over that data and compare those.

However, I don't know how time-consuming such a checksum-calculating would be.