On Saturday 30 December 2006 18:36, Tim Ansell wrote: > > > > > * 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.)
Which tpserver-cpp does not do. Therefore, you should check the feature frame to find that tpserver-cpp does not support this optimisation, and therefore you have to get the whole objectid list. As to your optimisation when using other servers, that is a problem. Maybe those servers need to put those objects in as changed with very recent modtimes. > 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.) You should ask for at least 100 at a time to efficiently use bandwidth (ethernet frame size). > 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. All the mod times should be changed. What's the problem? Ahh, that little optimisation.... > 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. Not trivial. It is not a high priority to add such client-side optimisations at the expense of the server. > > > 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?) Could be. That would work. > Maybe this could be part of the new Game frame that the MetaServer > uses? I don't think it is important enough. The current set of metadata is fine currently. > You said you would be implementing caching in libtpproto-cpp so you may > run into these problems/requirements very soon too. Any thoughts? It is a balance between predictions (which could be wrong) and using bandwidth. I tend toward the latter, but try to spread it over time, so that it isn't too disruptive. > Mithro Later Lee
pgpLiLU0pU04U.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
