[Freeciv-Dev] Re: [Patch][RFC] Reduce superfluous tile_info packets

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Oct 25, 2001 at 06:07:32PM -0700, Raahul Kumar wrote:
> 
> --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Thu, Oct 25, 2001 at 06:15:00AM -0700, Raahul Kumar wrote:
> > > I quite like that. It's a good thing packets sent are being reduced
> > > considering that
> > 
> > > when the CMA goes into CVS, the total amount of packets sent is
> > > going to increase dramatically.
> > 
> > Although I have no numbers I doubt this.
> > 
> 
> Take the current case. Jack is playing a freeciv game. He creates an aifill
> of 7 players. Two different scenarions happen in the client side ai vs
> server side
> 
> Server side(the current way)
> The ai never gets sent any packets about the location of its units. No packets
> about anything basically. And needless to say, the slowest part of the 
> equation
> in playing Freeciv is the dial up connection. My Athlon 800 has no problem
> with rendering the graphics, or the AI warmap maths.
> 
> Client side(the new way)
> 
> 7 client side AI's need at the bare minimum the info on where their cities
> and units are. This has to be through packets.
> The AI's need to communicate to the server the unit moves, change in city
> production, change in worker tiles, etc etc that the server side ai does not.
> 
> It is impossible for a client side AI to send as few packets as a server side
> AI.
> This is always going to be true for absolutely any game. This is not an
> argument
> against client side AI. After all, I quite like the agents. They're already 
> an important part of my gamestyle.

Ok.

> > > A client side ai is always going to send far more packets than a
> > > server side one.
> > 
> > With a client side AI you save the packets a human player would cause.
> > 
> > > Maybe bzip2 should be considered.
> > 
> > No. Trust me there are other solutions which yield more reduction then
> > a normal compression.
> > 
> Believe it or not, Raimar, I am not telepathic. Do not hesitate to let me know
> what these solutions are.

With the two patches applied the biggest packets are still city_info
and player_info. But only a small amount of them change. So I'm
thinking of a bitfield at the start of the packet which tells which
fields have changed and all fields which aren't changed are also not
submitted. Another idea is to not use a bitfield but chunked
approach. The serialized city_info can look like this:
 int city_id;
 char PRODUCTION_HAS_CHANGED;
 int new_production;
 char SHIELD_STOCK_HAS_CHANGED;
 int new_shield_stock;
 char END_OF_PACKET;

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "These download files are in Microsoft Word 6.0 format. After
  unzipping, these files can be viewed in any text editor, including
  all versions of Microsoft Word, WordPad, and Microsoft Word Viewer."
    -- http://www.microsoft.com/hwdev/pc99.htm