[Freeciv-Dev] Re: Notes and serial numbers

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Sep 05, 2001 at 11:17:21AM +0200, Christian Knoke wrote:
> Am Mittwoch,  5. September 2001 09:29 schrieb Raimar Falke:
> > On Mon, Sep 03, 2001 at 12:50:19AM +0200, Raimar Falke wrote:
> > > On Sun, Sep 02, 2001 at 03:18:45PM -0700, Trent Piepho wrote:
> > > > On Sun, 2 Sep 2001, Raimar Falke wrote:
> > > >
> > > > So your goal here is to make certain that modem players can never
> > > > run a server and will have a bigger disadvantage whenever they
> > > > try to play with other people?
> > >
> >
> > I made some more testing with my current patch. The average packet
> > size is even lower:
> >
> > [...]
> >
> > The average size without sno would be 30-4=26 bytes/packet. This is
> > an increase of 15.4%. BAD. I have some ideas how to reduce this.
> >
> 
> In your initial statement you pointed out, that most packets
> the client sends already get an answer, either a positive
> (execution of command) or a negative (error message). Why
> don't you make sure, an error message is sent in every
> error situation (e.g. land unit tries to walk into the sea)?
> 
> This could also be a benefit for human players: it happens
> to me in network games that I get no reaction for a command
> and wait and wait ...
> 
> Just a generic message, which is translated into text on the
> client side.
> 
> Guess this needs less bandwidth than a serial number.

I have concealed anothe reason: the agents has to know when the object
it currently changes is also changed from outside. Let me give you an
example:
 1) a city has a certain state s1 (both client and server are synchron)
 2) the agent decided that something in this state has to be changed
 3) agent/client sents a request to the server
 4) client receives a city update from the server of this city
 5) client receives a execution-finished packet for the previous
 request
 6) agent checks the now current client state of the city for the
 expected changes

At 4) the client has to decide if the updated information are caused
by the request or somebody outside (a diplomat can have poisoned the
citizen). If the change is from outside the city (id) is put into the
please-check-these-cities queue of the agent to be reevaluated after
step 5). Summary: the client has to know which packets are caused by
the request.

My current plan is relativ easy: additional to the execution-finished
packet there is a execution-started packet. These packets frame all
packets which are caused by a given request. Since the server is
single threaded and only processes one packet at a time this is
possible. This is also bandwidth saving because only all requests
(client->server) and the execution-started packet have to carry
snos. So this is a fixed overhead of (4 (extra snos for request) + 7
(execution-started) + 3 (execution-finished))=14 bytes per request.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Are you saying that you actually used the Classpath Java AWT classes in 
  addition to the GTK peers and got them to display something?
  Wow.  That's way better than I did and I wrote the code!"
    -- Aaron M. Renn in the classpath mailing list