[Freeciv-Dev] Re: Notes and serial numbers

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Sep 05, 2001 at 12:05:23PM +0200, Raimar Falke wrote:
> 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.

You don't need the second sno. Now you can also change the name from
serial number to request number. This gives (2 (request number for
each request) + 5 ((execution-started) + 3
(execution-finished))=10bytes per request. It looks like this feature
will be always on ;)

        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