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> Sent: Tuesday, January 26, 2021 6:45 AM To: dev@geode.apache.org <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> Sent: Friday, January 22, 2021 10:41 PM To: dev@geode.apache.org <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> Sent: Friday, January 22, 2021 8:35 PM To: dev@geode.apache.org <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> 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%7Cdasmith%40vmware.com%7C776eddfeec43423ccfee08d8c2091d4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637472691702967826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jRf5gJ7UIlCnrK%2FLfH6fSg1yLtb3%2BMdc3krwkOvtJA0%3D&reserved=0 > > Could you please provide feedback by Tuesday, February 2nd, 2021? > > Thanks, > > Alberto G. >
