On Tuesday 02 January 2007 20:12, Tim Ansell wrote: > > > 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".)
I don't directly use the backend in such a way. The player has a set of object id's that the player can see. As each is put in the ObjectIdsList frame, the Object Manager is queried for each object in turn, fetched from the database as necessary, and the modtime placed in the frame. The Object Manager acts as a cache for Objects in the server. The STL for multimap is not something I have tried before, and I'm not confident of it's speed, memory usage or consistency. The "optimisation" is what is causing your problems. It is probably the wrong one. Maybe a better way would be to grab the objects/data that the player will want straight away, such as their board and home planet/owned objects, and grab the rest when the player needs it or when they aren't doing anything. > 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. in fact 10000* 12 / 1024 = 117 KB GetObjectIdsByPosition exists for a reason. You would be lucky to show 10,000 objects on screen, much simplification would be needed. > 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. Not a nice solution. > > > 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". Wouldn't happen in tpserver-cpp. Creating a new game would reset all the modtimes to that time (except things that i don't track the modtime on). > > > > > 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. Sending ids isn't a problem, really. > > > > > 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. I meant it isn't important enough to send to the Metaserver. I am happy for it to be in the Game statistics (or whatever) frame. > > > 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. Then if you have a problem, you are making the wrong predictions. > > > Mithro > > > > Later > > Lee > > Mithro Later Lee
pgpXOeX5y1lOx.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
