Medium to Large code/design tasks

Rising ourselves by our own hair.
Post Reply
User avatar
Posts: 397
Joined: Thu Jan 10, 2013 3:40 pm

Medium to Large code/design tasks

Post by nemerle » Mon Mar 25, 2013 7:43 pm

I think we need to split all communication Events into a 3 parts
State - the class/structure that stores the given part of the world data, and can create a Delta, given another State.
Delta - a class that stores the difference between 2 State classes ( this is used very often in the CoH client-server communiacation to reduce used bandwidth )
Serializer - a class that can read/write either State or Delta to a Bitstream.

State - Delta design will be a little bit tricky, since for each connected client the collection of State objects will have to be maintained.
ClientState is basically a server-side model of 'What we think given Client "knows" about the map/entity/other State'. Whenever a packet is acknowledged by the Client, we need to update the server's ClientState with the acknowledged Delta/State.

I think we'll end up with a bit strange design, and I'm not at all sure this is the way to go, does this look overly complicated to anyone ?

Code: Select all

Map - Model    [ Authoritative Model of the Map, updated by physics, AI, and other subsystems ]
      |  1
      |  *
Client Model   [ Last client acknowledged State, the delta between this, and current MapModel is what's got to be sent to the client fairly frequently ]
      | 1
      | 0..*
   Delta          [ Each of those can be acknowledged which should invalidate all older Deltas, and update the ClientModel by that Delta ] - This looks very data base'y  ( 'commit' anyone ? :) )
Thinking out loud
Problematic sequence:
Given the following contents of the ClientModel, when the MapModel_t4
ClientState_t0 [x=1] -> Delta_t1 [ 2 ] -> Delta_t2 [ 3 ] -> Delta_t3 [ 1 ]
When the client acknowledges receiving Delta_t2 the following things must work:
Acknowledging Delta_t3 - we must be able to 'commit' the Delta_t3 over updated ClientState_t2, even though the Delta_t3 was created between ClientState_t0 and MapModel_t3
Possible solution: when Delta_t2 is acknowledged, update Delta_t3 with negative Delta_t2 : ( ClientState_t3 = (ClientState_t2-Delta_t2) + Delta_t3)
Drawback 1: if we have many Deltas following Delta_t2, it might be inefficient ?
Drawback 2: All deltas must be reversible ( what is the inverse of 'delete entity 1' delta ?)

Sending a Delta_t4 - we need to send a new delta at time 4, we send it using ClientState_t2, what happens when the Client receives our delta, and it has just updated it's ClientState using Delta_t3 ?
"Ich was in one sumere dale,
in one suthe diyhele hale,
iherde ich holde grete tale
an hule and one niyhtingale."

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest