[Freeciv-Dev] Re: Notes and serial numbers

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Wed, 5 Sep 2001, 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.

I may well be missing the point here, but couldn't you just add "beginning
of responce to your move <checksum>" to the first packet and "end of
responce" to the last packet?  The <checksum> could be a one byte checksum
of the move (for one player, this should be unique), eliminating the need
to send a serial number.  This brings it down to three bytes, with no
added packets, which should mean a very small performance loss (I don't
have the background to code and measure it).

Of course, I might have no clue what I'm talking about.
--Daniel Speyer
"May the /src be with you, always"



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