Re: [crossfire] Crossfire protocol cleanup
Brendan Lally wrote: On 10/9/06, Mark Wedel [EMAIL PROTECTED] 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
Re: [crossfire] Crossfire protocol cleanup
On 10/9/06, Mark Wedel [EMAIL PROTECTED] 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire protocol cleanup
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: snip/snip I agree code cleanup could and should be done, including removal of old and deprecated things. I also support Brendan's idea to have an intermediate release with still the setup command for 2.0 stuff, so there could be an intermediate release. We could simply remove the arguments of the setup command, and keep it for new (post 2.0) things. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire protocol cleanup
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? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
