+1

This proposal makes a lot of sense.

Besides, I recently sent a proposal to allow clients to communicate with 
servers in an older version in case the compatibility was not broken in the new 
version of the client ([1]). With your proposal, the aim of that RFC could also 
be achieved. Following the example you have added to the JIRA ticket, a client 
with version 1.17 would be able to communicate with servers with version 1.15 
or 1.16 given that the client server protocol for the client would be 1.15.

[1] 
https://cwiki.apache.org/confluence/display/GEODE/Add+option+to+allow+newer+Geode+clients+to+connect+to+older+Geode+servers

BR,

Alberto G.
________________________________
From: Bruce Schuchardt <bru...@vmware.com>
Sent: Tuesday, February 23, 2021 6:38 PM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: [DISCUSS] client/server communications and versioning

I’m considering a change in client/server communications that I would like 
feedback on.

We haven’t changed on-wire client/server communications since v1.8 yet we tie 
these communications to the current version.  The support/1.14 branch 
identifies clients as needing v1.14 for serialization/deserialization, for 
instance, even though nothing has changed in years.

If we put out a patch release, say v1.12.1, clients running that patch version 
cannot communicate with servers running v1.12.0.  They also can’t communicate 
with a server running v1.13.0 because that server doesn’t know anything about 
v1.12.1 and will reject the client.  To solve that problem we currently have to 
issue a new 1.13 release that knows about v1.12.1 and users have to roll their 
servers to the new v1.13.1.

I propose to change this so that the client’s on-wire version is decoupled from 
the “current version”.  A client can be running v1.14.0 but could use v1.8.0 as 
its protocol version for communications.

This would have an impact on contributors to the project.  If you need to 
change the client/server protocol version you will need to modify 
KnownVersion.java to specify the change, and should let everyone know about the 
change.

See https://issues.apache.org/jira/browse/GEODE-8963

Reply via email to