[Freeciv-Dev] Re: [Patch] Making city report list faster

[Per I Mathisen <per@xxxxxxxxxxx>]

On Mon, 10 Jun 2002, Raimar Falke wrote:
> > This patch fixes the second problem: when you change something in the
> > city report, the report is "frozen" until the last change is confirmed.
> >   Thus (to take an extreme, but possible example) if you change 100
> > cities all at once, instead of having 100 graphical updates there will
> > just be one (this is important since graphical updates are quite slow).
> >   (It looks like it does this by monitoring the request ID, which is a
> > direct result of work for the CMA.

Sounds very good, but what happens if there is significant lag between
client and server? Will anything except the city dialog be frozen?

> > However, there is still lag: the change cannot be made until the last
> > packet from the server is received.  I think there is a better, and more
> > general solution that is possible.  When a change is made by the user in
> > the GUI, the client should change that data internally _as well as_ send
> > the request to the server.

Lazy write should be possible for this dialog, but I would be wary of
extending it further.

> Nice idea but there are problems. For example there are GUI changes
> which are rather hard to undo for the user:
>  - change via the city report and the client print "Production changed
>  in London from foo to bar." But no the server rejects this
>  change. What should happen? Add a "Well ... take this back London
>  still produces foo."? Seems odd.

Maybe odd, but quite possible. "Illegal production in London, reverting
production from bar to foo." The user will understand. Since the client
has very good information about allowed production targets, it will only
happen in very rare cases (eg arbitrary effects from server scripting).

>  - founding a new city: the user press 'b' and press return to accept
>  the city name. The new city dialog pops up. The user changes the CMA
>  settings. And POP the server decides that the city isn't allowed at
>  this location. Very odd if you than pop the city dialog down and
>  remove the city from the map.

Agreed.

However, one other way to address this is to fix the network layer. If you
could send multiple change requests in one packet, it would help a lot.

Actually it would be nice if we had a network interface which could
serialize Freeciv packets, combine and split them into network packet size
chunks and send them, then deserialize them on the other side. (Attributes
do this already as a special case.) This way we would get much more
efficient network usage.

Also there does not look like there is any reason for the constant
malloc/free'ing that goes on in the network layer. The max size of the
packet is constant and is not big, and only one packet is processed at
once, so we could just as well make it a static buffer, as suggested
earlier.

Yours,
Per

"It is difficult to catch a black cat in a dark room.
Especially if there is no cat there." - Confucius