[crossfire] Crossfire protocol cleanup

[Mark Wedel]

Brendan Lally wrote:
> On 10/9/06, Mark Wedel <mwedel at sonic.net> wrote:
>> - May not be able to use a 2.0 client to play on an older server (depends on how
>> old, and what protocol commands to use).  Could still use the 1.x clients of course.
> 
> Might I suggest then, that when the 2.0 protocol changes are (vaguey)
> finalised, a version of the 1.x server be released which understands a
> 2.x version number and acts as though all of the appropriate setup
> flags were set (without adding any of the new features), and also is
> aware of any new commands that can be sent to it, but merely ignores
> them (with suitable draw_info-ed error messages). That way it should
> be possible to have a compatibility upgrade to the server allowing
> both sets of clients to work for however long it would be until most
> distros have upgraded the versions they ship.

  It's really hard to say how well that will work until all the changes to the 
protocol are done.  And I don't know right now what all those changes may be.

  There are several potential issues:
- Some existing protocol command is removed from the trunk branch, replaced by 
something else.  In this case, it is easy for the client or server to ignore the 
command, the problem is that if this command has critical information, doing so 
results in a broken setup.  This scenario probably isn't too likely.

- An existing command is extended to include values it did not include before. 
Depending on the direction of the command, this may or may not be easily 
handled.  For example, if the 2.0 server will send some existing values that the 
1.x server won't, that probably won't cause any issues for using a 2.0 client on 
a 1.x server (it can handle those values, would just never get them).  A 1.x 
client on a 2.0 server will have problems - it will get what it sees as bogus 
data in some commands.  The protocol commands are not self documenting, so the 
best the client can do is just ignore all data after that bogus value (it won't 
know the size of the bogus data so won't know how much to skip, etc).  And if 
the change is in the C->S direction, then scenario is reversed - 2.0 client on 
1.x server would have issues.  I think this scenario is fairly likely to occur.

- New values are not added, but rather the meaning or type of existing values 
are changed (something is currently sent as 16 bits, we decide it should be 32 
bits, etc).  This basically has all the same issues as the point above.

  So going back to the original point of the post, which was having a 1.x client 
that could play on 2.0 servers, this is what I would see have to be done:

1) the 1.x client would have to fully understand the 2.0 protocol.  anything 
less, and there is too great a risk of serious functionality be missing or bugs 
happening, etc.

2) For this to make sense, this 1.x client would have to be released quite a 
while before 2.0 is released.  releasing it 2 weeks before 2.0 wouldn't make 
sense - at that point, just grab the 2.0 client, etc

3) Such a client would still have to know/be valid on the protocol version 
numbers.  The client itself could change what SC/CS_VERSION it reports to the 
server based on what the server tells it (basically lie).  It would then choose 
not to do the setup command based on this.

4) To be compatible with 1.x server, basically all the code related to 1.x 
protocol commands has to be retained.

  Now as I type all this in, I see a major problem.  If we do the above, it 
basically removes/obsoletes the 2.0/trunk version of the client.

  If the 1.x client is fully functional with everything, why do you need a 2.0 
client?  And it then makes other proposed changes more difficult (getting rid of 
some of the older client interfaces, doing a cleanup, etc).  It would pretty 
much mean that the 1.x client branch would probably have to be maintained pretty 
for the duration of the 2.0 release.  It's easier to remove old clients or 
support at the major release than later.  In short, if when 2.0 comes out, we 
say you have to use a 2.0 client, people would not their head and say OK.  If 
instead, when 2.0 comes out, you can use a 2.0 or 1.x client, it becomes very 
difficult when 2.1 comes out to say you can't use that 1.x client anymore 
(people will ask what has changed, what can be done, make patches, etc).  I 
don't mind this being unofficially supported (can't control that anyways), but I 
don't want to support it personally.

  So what probably makes more sense is this:  Release a 2.0 client some time (3 
months?) before the projected 2.0 server release, to allow time to make it into 
the various distributions, etc.  Maybe call it a beta release.  This 2.0 client 
could only be used on 2.0 servers (likely missing support for 1.x servers).  At 
the time of the client release, the 2.0 protocol version strings are frozen, and 
any changes made to the protocol have to go back to using the setup commands.

  This may have other advantages - I'd expect as we get near, we'd have various 
public servers running 2.0 code for testing purposes - for that reason, having 
some clients out there would make sense.  The downside is that these 2.0 clients 
can be used on 1.x servers, but that probably isn't that big an issue.  I don't 
think there should be anything preventing a use from having both 2.x and 1.x 
clients installed on a system, or if there are things preventing it, it probably 
just means changing the pathname here or there.