Complete.Org: Mailing Lists: Archives: freeciv-dev: March 1999:
Re: [Freeciv-Dev] 1.8.0 and network byte order
Home

Re: [Freeciv-Dev] 1.8.0 and network byte order

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] 1.8.0 and network byte order
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Thu, 4 Mar 1999 20:54:37 +1100

Trent Piepho wrote:
> On Thu, 4 Mar 1999, Mitch Davis wrote:
> > If the network byte order is wrong, then won't the major
> > version of the protocol in the first packet be 0x01000000
> > instead of 0x00000001?  This seems like an easy way to
> 
> Only problem is the join game packet will not be received properly, because
> the length will be wrong.  Basicaly the server will think the packet is 256
> times larger than it is.
> 
> One could check the size of the packet, if the PACKET_REQUEST_JOIN_GAME is
> larger than about (17*256) bytes, there is a byte order conflict.
> 
> The problem is that the server or client will not process a packet until all
> of the packet arrives.  Since they think the packet is so big, that will
> never happen.

Well, here is a patch to which uses the above information :-)

The server checks the claimed length of the first packet
it receives from a connection, and if its over 1024
(4 times 256, minimum byte swapped length and well
over normal length of about 28 for first packet;
could be made larger as above?) it considers that 
connection byte swaped.  It uses that information to 
re-write the length so the packet gets processed correctly, 
and to unswap the join game packet.  Capabilities then 
take over to reject the client, and the byte_swap info is 
used so that the old client gets a failure message
(with the appropriate byte swapped length so it works).

So this protects new servers from old clients.  I don't
know how to fix the case of new clients connection to
old servers, since there the client initiates, and the
old server accepts the initial connection (at the socket
level) but never processes the join_game packet because
of the wrong length.  And the client never gets back
anything to work with.   Maybe some timer in the new 
client that if it doesn't get a reply after some time 
it breaks the connection?

Patch summary:
- includes network byte order code from Trent Piepho
- includes extra headers suggested by Mitch
- handles first packet specially, to detect and deal 
  with byte swapping (on the server) as described above
- capability changed to "+1.8pre2"
- minor cleanups in sernet.c  

Regards,
-- David

Attachment: byte_order_d1.diff.gz
Description: GNU Zip compressed data


[Prev in Thread] Current Thread [Next in Thread]