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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jun 10, 2002 at 10:51:58AM +0200, Per I Mathisen wrote:
> 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?

No.

> > > 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.

You can use the processing packets to do this as the patch does. Plus
they are required for agents.

> 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.

This is nonsense. What overhead do you want to avoid? TCP/IP overhead? 
Than insert connection_do_buffer/connection_do_unbuffer calls if you
know that you send multiple changes. sernet.c:sniff_packets does this
(this means that all response of a request are send back in one TCP/IP
packet). Also the CMA does this.

If you talk about freeciv-packets overhead: where do you think can you
make them smaller if you package them WITHOUT introducing a lot of
special packets. Note that for attributes the overhead isn't small:
for every attribute you need to record the size of the value (+4
bytes). If you serialize the hash you need 16 bytes per entry (plus 8
bytes fixed size). Than you have to split the block into chunks which
adds another 12 bytes. So for one entry you have an overhead of 40
bytes. You can send two city_requests with this.

> Also there does not look like there is any reason for the constant
> malloc/free'ing that goes on in the network layer.

You mean 

receive_packet_diplomacy_info(struct connection *pc)
{
  struct pack_iter iter;
  struct packet_diplomacy_info *preq=
    fc_malloc(sizeof(struct packet_diplomacy_info));

and similar?

> The max size of the packet is constant and is not big

This doesn't matter since the data is decoded and can use more memory
in it's decoded form.

> , and only one packet is processed at once, so we could just as well
> make it a static buffer, as suggested earlier.

Yes this can be done.

Question: how much overhead is this? Can it be measured?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Two OS engineers facing a petri net chart:
        "dead lock in four moves!"