[crossfire] Crossfire protocol cleanup

Mark Wedel mwedel at sonic.net
Mon Oct 9 02:37:39 CDT 2006


  Please note that everything discussed in this message only pertains to the 
targetted 2.0 release of crossfire, which is in the trunk.  Changes won't be 
made to the 1.x branch.

It has been noted that within both the client and server, there is a fair amount 
of old code around to support older versions of the servers and older versions 
of the client.  The setup command has also gotten a lot of options with methods 
to negotiate what protocol commands it supports, and directly related to that, 
there is a lot of code in the server that does/does not do something based on 
what has been negotiated.

  The idea here is to clean all that up for 2.0.  Specifically:

- Change the SC_VERSION and CS_VERSION to 2000, to represent 2.0 release.

- server and client must have some version to work correctly - mismatched 
versions may or may not work (client may get data it doesn't understand, server 
may get client commands it is unable to process)

- Version 2.0 compliance means that the client supports the latest 
implementation of the protocol.  Support for superceded protocol commands is 
removed from both server and client.

- Version 2.0 compliance also means that the client supports all the relevant 
items within the setup command, so that doesn't need to be negotiated (spell 
info, 64 bit exp values, whatever, so those are not needed in the setup command. 
  Note that there will still be some things done via setup, like faceset, map 
size, etc - things that are actual preferences, and not protocol selection info.

- While 2.0 is in development, any updates/changes to the protocol will result 
in updating the SC/CS version numbers, and not done via setup.  This may mean 
people need to update their client to play on their test server, but since this 
is while doing development, I don't think that is unreasonable.

- Once 2.0 does release, then any changes to protocol would go back to being 
enabled via setup commands like done now.

- If/when alphas/betas for 2.0 are done, both a client and server release 
snapshot is done, so no issue with version commands.

Pros for doing this:
- Helps in code cleanup (get rid of old code)
- Enables more rapid code development (easier to make protocol changes, and can 
remove obsolete code at time new code is added).  Note: This doesn't remove the 
need for discussion on protocol changes
- Simplifies protocol, make it clearer what new developers should program to.

Cons:
- Need 2.0 client to play on 2.0 server (would probably be a requirement at some 
point anyways)
- 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.
- Developers would need to keep their client and server in sync to play, given 
requirement of equal protocol versions (may not be that big a deal - I'm not 
sure how often the protocol will change, and doing svn updates shouldn't be that 
hard)

  thoughts?




More information about the crossfire mailing list