As these emails are getting very long I'm going to split this into a few separate lines of thought.
On Fri, 2006-12-15 at 21:31 +1300, Lee Begg wrote: > On Friday 15 December 2006 18:13, Tim Ansell wrote: > > When thinking about tp I've been trying to keep the following things in > > mind: > > > > * You should be able to use any client > > * Changing client's shouldn't loose you any information > > * Client's should be able to predict as much as possible (to reduce > > server load) > > Without a cache, there isn't much to predict, and I have been trying to keep > redundancy down. I agree with the above statements. <snip> > > > > * Better difference support. Currently there are problems with the > > > > fact that you could be running a different server when a person > > > > reconnects. What about objects disappearing? That too doesn't work to > > > > well. > > > > > > Currently, it shouldn't be a problem. I future, I plan that when a fleet > > > is lost in battle, the object id will remain, but the object would be a > > > debris field. That doesn't quite work for everything and objects must > > > eventually disappear from the universe. > > > > > > What is wrong with the object (or generic) id lists with their modtimes? > > > I know that tpserver-cpp doesn't support it on somethings, but they are > > > the sort of thing that doesn't change anyway. > > > > The id lists with modtimes almost work. The problem is that the list > > doesn't include objects which no longer exist. > > ...Which should give you a clue that they no longer exist since they are not > in the list. This of course breaks the optimisation where I stop downloading IDs once I find an object which isn't modified. (This requires the objects be returned in descending modification time.) With this optimisation if only 3 objects out of 10,000 changed I still only have to get 3 ids+modification times. (Which is likely to be a very common case.) This breaks badly if you connect to a server and the previous game you have data about no longer exists (IE A new game has started). This is why I want a "randomly generated key" as mentioned below so I can detect this change. This has occurred when tpserver-cpp is using the in memory DB and it accidentally crashes. > > It is also highly inefficient to download every single ID and it's > > modtime, you could have 15,000 objects in a game of which only a few > > changes occur (it would take up 1mb of downloads just for the ID > > +modtimes). > > In tpserver-cpp you will only get the object ids that you can see, which > should reduce it a little bit. But I can't think of a way to make it more > efficient. See the optimisation above. It should be pretty trivial for tpserver-cpp to return objects in descending last modification time. > > There is also no way to tell if this server is the same one you > > connected to before. For example, if the server gets restarted and was > > using the memory database objects will just "disappear" and it confuses > > the caching mechanism. > > > > I then each game should get a randomly generate key which I can check. > > Maybe add to the Features frame? > > Part of what I called "Game statistics" below would include when the game was > started, which could be used for that key. See above about why I want this. The value could just be the game creation time? (Which for tpserver-cpp with memory mode would be the startup time of the server?) Maybe this could be part of the new Game frame that the MetaServer uses? You said you would be implementing caching in libtpproto-cpp so you may run into these problems/requirements very soon too. Any thoughts? Mithro _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
