<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40581 >
I thought the request_id was intended to associate a packet sent to the client with the particular request that the client had sent to the server. Perhaps I digress, but - for instance: the player requests to buy something. The client does the check and finds the buy to be legit. It sends the buy request to the server. At the server end the buy succeeds and the city state changes, or perhaps the buy fails and a failed-buy packet (very rare as the client catches most such instances) would happen instead. Now at what point does the client state change? I don't know the current situation actually but there's two ways to do it. 1. When the client approves the buy and sends the info to the server, it goes ahead and updates the city info with the purchase. The server will most likely re-send the same info in a packet, which will result in, most likely, no change and no later update. However if the purchase fails at the server end the server needs to send a buy-failed packet which the client connects to the original buy attempt (very tricky and uses the request_id) and reverts the buy, or the server resends the original city info (which is actually an empty packet and all handled within the "delta" network code). The advantage is this works as well or better in all cases: only in the case of a failed buy is it any worse, and in the case of a high-lag connection it's better than case 2. The drawback is that the client needs much better checking of the purchase validity - including checking the game phase (not to buy in the middle of a turn-done or to avoid buying in one turn but through lag having the server handle the buy next turn). 2. When the server approves the buy and sends the city info back to the client, the client only then updates the purchase. This is, of course, safer and more reliable. But if there's a high-lag connection it'll be a lot less user-friendly - potentially cripplingly so. The saferness comes into play when a purchase fails at the server end; with case 1 you'd have the client incorrectly update the city info itself then receive the new (original) info back again and revert. Such situations would be rare however; they can happen with some rulesets or server mods maybe but are most likely to happen if the player tries to buy right as the turn ends and the server doesn't handle the request til the following turn. Okay having given that example, I still don't see a use there for the request_id. So how is it used again? Just as an outdated variant of the freeze/thaw mechanism? -jason _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
