[Freeciv-Dev] Re: Notes and serial numbers

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Sep 05, 2001 at 09:08:54AM -0400, Daniel L Speyer wrote:
> 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.

As I said in another mail it is now more like a request id than a
serial number. I have considered this. Where do you put the these two
bits? The only place is in the size field which is 16 bits wide. As
for the one byte checksum. I have also thought about this and I think
it may be possible to have more than 256 outstanding requests.

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

It is possible but I think it is ugly to put these two bits into the
size field. I think 10 bytes / request is acceptable.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  (On the statement print "42 monkeys"+"1 snake"): BTW, both perl and Python
  get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when 
  the answer is clearly "41 monkeys and 1 fat snake".  
    -- Jim Fulton, 10 Aug 1999