<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
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?
Freeciv-dev mailing list