[Freeciv-Dev] Re: (PR#6585) Delta version 5

["Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=6585 >

On Tue, Oct 21, 2003 at 10:05:27AM -0700, Raimar Falke wrote:
> 
> 
> This is a new release of delta protocol. The delta protocol is an
> effort to reduce the bandwidth usage of the client server
> communication. For the ideas, technical details and results please
> visit the thread "[RFC][Patch] Reduce bandwith by using deltas".
> 
> The differences between previous version and this version are minimal.
> 
> Open points are:

>  - "unknown event 0". seems like a small bug to me

Fixed.

>  - the client dumps core at disconnect. will be fixed if the code is
>  updated to current CVS.

Fixed.

>  - auto* detection for zlib

Done.

Other changes from last version:
 - updated to current cvs
 - added documentation to generate_packets.py
 - added documentation to HACKING
 - rename files so that now all generated files match "*_gen.[ch]"
 - merge serveral handling files in server/ to "hand_gen.h"
 - add no-handle flag to packets
 - fixed a bug in the no-delta mode of generate_packets.py
 - converted the remaining packets
 - adapted the gtk2 and xaw client
 - added support for environment variable FREECIV_COMPRESSION_LEVEL
 - group packets in packets.def

Still open:
 - capability support
 - corruption with FREECIV_COMPRESSION_LEVEL=0. I have no idea was is
 causing it. I think I have rules out the case that the freeciv code
 allocates a too small buffer. Valgrind also doesn't help here.
  Jason, Per: maybe you are able to find the bug.
 - adapting other clients (sdl, win32, mui). I can't and won't do
 this. It is also an easy task.

The patch is against CVS HEAD. No generated files are included. They
will be generated.


And now some numbers. I used the 'Honecker+1490.sav.gz' savegame from
PR#6754.

If you set "disable_delta" to 1 in generate_packets.py you get a
"classic" (non-delta) protocol. Orthogonal to this is the compression
feature.

The first line is amount of bytes the server sends during game
startup. The second line is for the new-turn data of the 5 next turns.

The format is uncompressed/compress (with the default-level (6))
size. The remaining numbers right and bottom are the various factors.

no delta:
  start   130753/39766  3.3
  5 turns 149023/34708  4.3

delta: 
  start   105965/37491  2.8
  5 turns  19817/ 9466  2.1

no delta -> delta
  start     1.23/  1.06
  5 turns   7.5 /  3.7

total factor start   = 3.5
total factor 5 turns = 15.7

So a delta without compression for the running game will reduce the
traffic by a factor of 7.5. Compression without delta will reduce it
by factor of 4.3. Delta with compression achieve a factor of
15.7. That is quite nice. The factor for the startup traffic isn't
this large because delta can't do much here. But the compression by
itself achieves a factor of 3.

So for this non-trivial game only 1183 bytes will be sent on average
during the new turn. This is even with slow modem not an issue
anymore. The data which is sent during game startup (37k) may however
still be a problem. With a 56k modem you need to wait about 6s here.


The patch changes a lot of code. I'm sure that it isn't error
free. Please test it hard. Please test especially the diplomacy
because it was changed much.

Since the patch has a high rate of becomming stale I plan to apply it
in a week.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."

delta7.diff.bz2
Description: Binary data