<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40581 >

I propose that all request_id related code be removed,
since it unnecessarily complicates connection handling,
causes side-effect bugs and desynchronization between
the client and server (due to its state dependence),
and generally does not help much if at all in the few
situations where it is actually used.

In particular I move that the following fields be
removed from struct connection:

bool is_server;
int client.last_request_id_used;
int client.last_processed_request_id_seen;
int client.request_id_of_currently_handled_packet;
int server.currently_processed_request_id;
int server.last_request_id_seen;

and all code that references these.


As for the original intended use of this mechanism, which
I presume was to allow the client to cut down on expensive
gui updates when the server would send a burst of info
packets, though there are already other existing systems
for that (e.g. PACKET_FREEZE_*), instead of co-opting those
I propose that packet definitions and the client/server
packet handling code be modified so that the inefficient
mass sending/update situations be avoided.

So for example the client would only add/remove/update the
gui element corresponding to the object referenced by the
info packet, and not refresh all such elements each time
a packet is received.

Both the client and server packets should be able to specify
multiple targets when sending a modify request or info, so
as to avoid update inefficiencies and to allow both programs
to optimize such cases. This could be for example a list of
city IDs for changing/buying production (a common mass-city
client request), or multiple unit IDs for moving, etc.

If still gui updates are problematic, the client can wait
until its event loop is idle before doing the gui refresh
(using for example a gtk idle function). Though I would hope
that with clever design that would not be necessary.


Thus I would hope that now that we are free to redesign the
packet protocol to best fulfill the current known use cases
of the program, the old work-arounds and ad hoc code can
be removed and a better designed system be put into place.

I'll leave this request-for-comments for quite a while so
that all who would care to respond can provide their input,
though I will not take silence as approval (so worst case
nobody reads this and nothing gets changed ;)). In the mean
time I will check further the current code structure to
make sure the proposed changes are feasible and can be made
without resorting to massive re-write patches.


-----------------------------------------------------------------------
春には掃除しましょうか。



_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to