> > > > 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.
I was hoping to start *requiring* this optimisation in the future. I find it hard to believe that it would be hard to do on any server? (If you have a database backend "SELECT id, time FROM table ORDER BY time ASC".) It just such a useful property if we could figure out the disappearing object bug. Getting 10,000 ids ***ON EVERY CONNECT*** (rather then just on the first connection), is quickly going to suck. >>> 10000*(8+8)/1024 156 156 kbytes!? and I haven't even gotten any information useful to the player yet. A possible solution is that object id and modification times NEVER disappear, even if an object does. This however means that there would be a larger initial download of ids. (As it includes all objects id's which ever existed.) They could however be pruned as long as a client logs in at least every pruning period. > > 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). I currently ask for them (ids/modification times) 30 at a time, but it is configurable. > > 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.... There is also the very unlikely case where an object in the game has the same ID and a lower modification time then the previous game. IE Initial Game, Object 10 - modtime 100 Replacement Game, Object 10 - modtime 10 I guess I could check for modification times "going backwards". > > > > 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). > > > <snip> > Not trivial. It is not a high priority to add such client-side optimisations > at the expense of the server. Well it's actually an optimisation which helps both client and server. Instead of the server having to send 10,000 ids it only has to send 100 or so. > > > > 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. It's important enough that it's caused issues in the past and I think if we don't fix it it will cause issues in the future too. > > 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. I want all predictions to be (pretty much) guarantee to be correct. IE The design stuff should be correct as long both sides are using the same code. > > Mithro > > Later > Lee Mithro _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
