[Freeciv-Dev] Re: Packet format question

["Forrest Sondahl" <forrest@xxxxxxxxxxxxxxxx>]

Thanks for your suggestions, Jason.

Yes, the Java code is actually being created by a modified version of
the generate_packets.py script.  At least, the class hierarchy that
corresponds to the different packet types, etc, is automatically
generated.

However, the code that puts the bytes from the packet into a buffer,
and does the delta-header decompression stuff, is written from
scratch.

I'm just baffled, because I feel like the packet

0 8 39 4 8 0 1 0

isn't a valid packet -- it's claiming to have some fields that just
aren't there.  I considered the possibility that I was truncating the
packet by not reading it fully from the tcp/ip stream, somehow, but
the fact that the first two bytes are 0 8, should mean that the whole
packet is only 8 bytes long, which it is.  Curious...

Maybe the README.delta file will provide some illumination.

~Forrest

> Forrest Sondahl wrote:
> > I'm a graduate student, involved in a project to develop a
> > general-purpose strategic game-playing AI.  We have some Java code
> > that reads the "packets" from a Freeciv server (version 2.0.1, for
> > reasons I won't go into...), and it works for a lot of the packets,
> > but it keeps choking on certain packets -- so maybe I'm not
> > understanding the delta compression, or something else..
> >
> > Here's an example packet, which our program fails to read, given as 8
> > bytes, printed in decimal.
> >
> > 0 8 39 4 8 0 1 0
> >
> > 0 8 - This is always the length of the packet, right?
> > 39 - This is the packet id -- a PLAYER_INFO packet.
> > 4 8 0 1  - I thought these bytes represented the delta-header
> > Which would be a string of 31 bits:
> > 00000100 00001000 00000000 00000001
> >
> > Which suggests that there are three fields being sent in this packet.
> > But there is only one more byte, which is a 0.
> >
> > At first I thought perhaps the packet was malformed, but I see these
> > (and similar packets) rather frequently, there must be something about
> > the format that I'm not understanding.  It happens most often on
> > PLAYER_INFO packets, but also some others...
> >
> > Any help that anyone can give me would be most appreciated.
> >
> > Also, if anyone could point me to some documentation or discussion
> > about how arrays are sent as "diffs" in the packets, that would be
> > most helpful...
>
> You might do better to extend the generate_packets.py program to also
> provide java code (likely depending on a command-line parameter).  This
> should actually not be that hard...although it may be tedious.
>
> -jason
>