On 12/16/2010 2:13 PM, Steve Simmons wrote: > The version report we get from rxdebug -v is useful, but as others note, it > can and is set by various sites to reflect their local needs. A 'core > version' flavor that strictly follows AFS releases would be useful, eg, > rxdebug -coreversion would only report a string the user shouldn't muck with. > And yes, I know that git-ish things have to be considered, yadda, yadda. The > devil is always in the details.
The bigger problem is that the version number of the RX library has no relationship to the version of the service that is running on top of RX. While it is true that the current OpenAFS servers using static linkage on UNIX, this is not true on Windows and is not necessarily true for alternative implementations of the AFS3 protocols. The appropriate place for structured version information is in each of the RX RPC client and server modules. The server needs to know what version the client is in order to understand how to work around client bugs and the client needs to know what version the server is in order work around server bugs. The Capabilities RPC could be replaced with a version that requires that the initiator advertise its version and get back the version of the peer. However, I do not believe that making use of such knowledge is a panacea. For starters, adding code to work around past bugs increases the complexity of the code. Not only for those that are reading it but for those that must test it in the future. We have too many code paths that cannot be tested today. How are we supposed to test that the bug avoidance code paths continue to work in the future? Another concern of mine is that version numbers are local. I know sites that have patched the version string to report a magic version number that is unrelated to the release they are based upon because policy states that they can't "upgrade" but they are permitted to fix bugs. Since their servers are contacted by publicly distributed clients, the clients may begin to execute code paths based on version number that is completely inappropriate. Even in less extreme cases, if you have 1.4.12 servers deployed today and you discover a bug and patch it, how are you going to locally modify the version number to reflect that? If you do modify it, then the bug work arounds for 1.4.12 will stop being triggered and if you don't modify then 1.4.13 clients that have a work around for 1.4.12 will begin to avoid a bug that you have already patched. Since you do not control the deployment of clients you can't ensure that there will be synchronization between when you deploy 1.4.13 and the new clients show up at your server's door step. In any case, this problem is not for OpenAFS to solve on its own. Any RPC work needs to be handled by the AFS3 standardization community. The appropriate place for any design work is on their mailing list. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
