[Freeciv-Dev] Re: clistat

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

Lauri Tarkkala <ltarkkal@xxxxxxxxxxxxxxx> wrote:

> On Mon, Aug 14, 2000 at 03:23:38AM +0100, Vasco Alexandre Da Silva Costa 
> wrote:
> > On Mon, 14 Aug 2000, David Pfitzner wrote:
> > > I wonder if it would be better to just add this information to the
> > > existing 'list connections' (eg, add an extra line for each conn),
> > > or add 'list clistats', rather than adding an new server command.
> 
> I wanted to create the command as quick as possible to test
> the buffering and asynch i/o of freeciv, so I did not want to mess
> with anything I was unfamiliar with, but making it a 
> "list clistat" would probably be best. 
> 
> For bigger games, where you have 10+ players, you probably don't 
> want to have 10+ excessive lines when you check who is playing..

Yep, agreed.

> > Lauri mentioned that the server network traffic was quite large (8.5MB in
> > 2 hours if i remember correctly).  Maybe that should also be looked into, 
> > if the traffic was smaller, the send_buffer wouldn't get full so quickly.
> 
> Yeah, we played a test game, and the server really does spam the client
> with data. Assuming that a client<->server connection is above 32kbps
> is IMHO not realistic or fair, as the international connections often
> tend to be worse than that due to congestion...
> 
> I think it might be worthwhile looking at trying to make
> the packets smaller by atleast an order of magniture. The game will
> become far more playable (in the later stages, when the
> maps become really big) for people with slower connections.

The freeciv "protocol" is rather inefficient in various ways.
Eg, even a small a change to a city will result in the server
sending _all_ of the data for that city.  Similarly for units
etc.  (OTOH if you have smaller more specialised packets, then 
you have more overhead per packet if you do end up sending all 
or most of the data, so have to find appropriate balance.)

Getting a better handle on sizes and types of packets would be
good.  (As well as looking at compression etc as mentioned.)

-- David