Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2000:
[Freeciv-Dev] Re: clistat
Home

[Freeciv-Dev] Re: clistat

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>
Cc: freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: clistat
From: Lauri Tarkkala <ltarkkal@xxxxxxxxxxxxxxx>
Date: Mon, 14 Aug 2000 09:54:15 +0300

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

> On second thought...  The send_buffer should be dynamic (i think David was
> planning this recently).  Whenever it goes full, it should grow in
> MAX_LEN_PACKET steps.  It could start with the current size of
> 10*MAX_LEN_PACKET.  This should make "lost" packets a rarer event (unless
> the send_buffer gets REALLY big (like 1Mb), or realloc fails - in that
> case we probably should cut that player connection.
> 
> 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.

An easy fix would be to use a simple huffman packer,
this would be relatively fast even on smaller systems. 

If zlib is efficient enough, it could be used to pack map-transfers,
which I think are the biggest cause. This would put more of a load
on the server, as it would have to pack/unpack data to all umpteen
connections, which is why a simple scheme might be "good enough".

I do not have any performance numbers on zlib? Anyone have any ideas?

Lauri

-- 
"The credit belongs to the man in the arena whose face is marred by dust and
sweat and blood, who strives valiantly, who errs, and who comes up short again
and again, who knows the great enthusiasms, the great devotions, and spends
himself in a worthy cause. The man who at best knows the triumph of high
achievement and who at worst, if he fails, fails while daring greatly, so that
his place will never be with those cold timid souls who never knew victory or
defeat." - Theodore Roosevelt



[Prev in Thread] Current Thread [Next in Thread]