On Thursday 04 January 2007 00:53, Tim Ansell wrote: > <snip> > > Well lets take a step back, what are we trying to do? We are trying to > download only things which have changed.
True. The things that are changed are the objects, boards, order descriptions,
resource descriptions, categories, designs, components and properties (at the
moment, more probably in future).
> So what do we need to do this? A way to figure out what has changed.
True.
> What type of changes can occur?
> - Object is created
> - Object is destroyed
> - Object changes
Yes. (Object in the general sense, but the objects will be the quickest
changes).
> A change can occur any time, IE A person puts a new order on an object
> is a change. (This means modification times must be a unix time stamp.)
Yes.
> I think it's safe to assume that the server clock never goes
> "backwards".
Absolutely. The only case I can think of that would could a backward shift
would be some sort of revert or restore from backup (after a crash for
example). If a backwards jump is noticed, I think everything would be invalid
(and therefore everything would need to be downloaded again).
> A client needs a way to ask "what has changed since the last time I
> asked?".
It is slightly more complicated than that. Note that is per-client-per-player.
So in actual fact, it should be (to be client independent) "what has change
since <timestamp>", where timestamp is the last known timestamp (or slightly
better/safer, one second before the last timestamp).
> Downloading all the object IDs and object modtimes seems very
> inefficient.
More efficient that downloading every object every time.
> What do you think would be the best way to do this?
Well, as I alluded to above, some sort of changes since timestamp might be the
best way. So the base frame (C->S) might look like:
* Timestamp, time, the time of last known changes
* uint32, max ids, the maximum number of ids to send
The base frame for S->C might look like this
* uint32, num changes, the number of changes since the time given
* Timestamp, last change in frame, the timestamp of the last change in this
frame
* list of (includes number of changes in the range in this frame)
* uint32, id that had changed between the time stamp in the c->s frame,
and the last change in frame above.
This way would allow both client and server specify how many ids to get/send,
the range of changes to get, the total number of changes, and the end
timestamp for the set of changes present. It is also smaller than the
current IdList frames because it doesn't send a timestamp with each one.
Thinking about this, I've noticed that this still suffers from the
disappearing object problem. Because it is a change system, disappearing
object ids should appear in the list. This isn't totally satisfactory though.
Any thoughts?
Another problem I still see is the amount of "unrelated", or more
specifically, "uninteresting" changes. A client could use the
GetIdsByPosition frame to get the ids (*all* ids) near their forces/position
and use the returned ids and modtimes to get the most relevant changes first,
and then the rest as necessary or when bandwidth allows.
> Tim Ansell
Later
Lee
pgpFmLNcqPSLW.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
