In my ideal world, the version represents the protocol version and not a product release number. As Dan points out, we could add a negotiation option to allow more flexibility between clients and servers.
To accomplish this we would need a simpler and well-specified protocol. The current protocol is pretty gnarly and difficult to piece together from the implementation. Complicating this is the fact that the protocol includes not only the message definitions but also the data serialization mechanisms for any data type included in a message. Given the challenge of answering “has any message or serialization changed?” we've taken the route of using release versions. Perhaps we could build an automated analysis tool that could answer this question and reduce frequency of version bumps to match when something _really_ changes. While some work has been done in this direction [1], it’s not far enough along to be a viable alternative as yet. Anthony [1] https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol On Jan 29, 2021, at 3:35 PM, Dan Smith <dasm...@vmware.com<mailto:dasm...@vmware.com>> wrote: Well, I have no objection to adding a system property for this if you want to try it. Since those properties aren't technically part of the public API I don't think we need to offer full support for what happens when the setting breaks. I'm just thinking ahead to what will happen when the protocol does change. At that point setting the system property will not work, unless the client has the capability to negotiate and discover the server version and use the old protocol the way that WAN does. Do keep in mind that failures may not be obvious if the serialization protocol changes and your client is pretending to be a different version. I think it's possible that the errors might show up only in log messages or corrupted values, and only if you are using whatever features are affected by a protocol change. -Dan ________________________________ From: Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>> Sent: Friday, January 29, 2021 11:40 AM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto:dev@geode.apache.org>> Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers Hi Dan, Thanks a lot for your comments. The scope of the RFC is not very ambitious. As I pointed out in it, the idea is not to implement the backward compatibility of clients with older servers. Rather, the aim is to allow to take advantage of the fact that serialization or other types of changes that may break this compatibility are not very frequent. For those cases where there have been no incompatible changes, with one of the proposed System Properties, it would be possible for a client to communicate with an older compatible server without the need of implementing anything extra. And we would have the test cases in place to assure this. For those cases where compatibility has been broken, it will not be possible to communicate the client with the older server and we would also have the tests showing that this communication is not possible even if the proposed System Property is used. I do not know how costly it would be to implement and maintain the alternative approach you suggest with the negotiation required to support full backward compatibility. I would leave that to a different RFC. The good thing is that the current RFC could serve as a first step to implement the second, if it is agreed that this second feature is worth of being put in Geode. Best regards, Alberto ________________________________ From: Dan Smith <dasm...@vmware.com<mailto:dasm...@vmware.com>> Sent: Friday, January 29, 2021 1:56 AM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto:dev@geode.apache.org>> Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers I think just sending the old version will only work until we actually make any changes to the protocol. Once we do, serialization will break unless we also change the client to pretend to be that old version, including the way it serializes and deserializes messages. With this proposal there will be no way for the client to use new features with a newer server since the version number of the client is set with a system property. An alternative would be to have the client and the server need a way to negotiate which protocol they are going to communicate over. We do this already for WAN. WAN senders can be a higher version than receivers, otherwise we couldn't upgrade an Active/Active WAN. What happens is that the WAN receiver will accept a newer versioned client, and it sends back its own version. The client reads the receivers version and adjusts accordingly. You can see this in ClientSideHandshakeImpl.handshakeWithServer. This will require a lot of testing to make sure that users won't see strange corruption related errors related to serialization changes. -Dan ________________________________ From: Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>> Sent: Tuesday, January 26, 2021 6:45 AM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto:dev@geode.apache.org>> Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers Hi, I have updated the proposal in the RFC by adding Patrick's suggestion (if I have understood it correctly). Best regards, Alberto ________________________________ From: Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>> Sent: Friday, January 22, 2021 10:41 PM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto:dev@geode.apache.org>> Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers Thanks for your comments, Patrick. Do you mean have the client always use in the handshake the oldest server version it is compatible with? Sounds like a reasonable simplification. In that case, I would use a flag to activate this behavior so that the current behavior (the client sends the current version in the handshake) is kept when the flag is not used. On the other hand if in the future we have clients that are partially compatible with an older server version, the System Property with the version could allow these clients to connect to that server version assuming that they will not use any incompatible feature. Alberto ________________________________ From: Patrick Johnson <jpatr...@vmware.com<mailto:jpatr...@vmware.com>> Sent: Friday, January 22, 2021 8:35 PM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto:dev@geode.apache.org>> Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers It sounds like you intend to test which versions are compatible with each other and maintain a list the client can use to reject the setting of force-version when set to an incompatible version. If that’s the case, why not just have the handshake look at that list and automatically connect with any versions that it is known to be compatible with? Then you wouldn’t even have to set the property. On Jan 22, 2021, at 11:05 AM, Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>> wrote: Hi Geode devs, I have just published the following RFC in the Geode wiki: "Add option to allow newer Geode clients to connect to older Geode servers" https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2Boption%2Bto%2Ballow%2Bnewer%2BGeode%2Bclients%2Bto%2Bconnect%2Bto%2Bolder%2BGeode%2Bservers&data=04%7C01%7Cbakera%40vmware.com%7Cf1de5be28b6443dbf6cb08d8c4ae99be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637475601476402147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eDrJB6ZMKqdCKLlylpGWRA1M1t80OldT7o65jmggvWc%3D&reserved=0 Could you please provide feedback by Tuesday, February 2nd, 2021? Thanks, Alberto G.
