Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Alberto Gomez]

After thinking about the pros and cons of the RFC solution and the 
alternatives, taking into account the comments received, I have decided to move 
it to the Icebox and not implement it for the time being.

Thanks all for the valuable feedback.

Best regards,

Alberto G.

From: Bruce Schuchardt 
Sent: Tuesday, February 2, 2021 5:41 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

Oh, but I forgot about WAN changes that may have been made to the handshake to 
allow different versions in different clusters.  Jake might be right about this.

On 2/2/21, 8:31 AM, "Bruce Schuchardt"  wrote:

I think it's only the locator connections that do this.  Regular 
client->server connections using the handshake code just send the client's 
current version, which must not be newer than the server's version.

On 2/1/21, 9:53 AM, "Jacob Barrett"  wrote:

Having just spent some time yanking out some of the really really old 
version support I think a naive version knocking approach would work. During 
the client handshake the server will reject and close the connection of any 
client with a newer version number than it supports. The client could use this 
as signal to downgrade its version and try again. This could continue until the 
server accepts the client. We would need to decide if we would expect the 
entire membership to be a the same versions or if the version knocking needs to 
be on a per member basis. Obviously knocking for every connection is not ideal 
so some sort heuristic should be maintained for the life of the client.

Interestingly enough the clients sort of did this up until the merge of 
this version cleanups. All clients first made connections using the very old 
protocol version so that the server would send its version back. Then the 
client would disconnect and reconnect using its current version. The same could 
be done today with the current protocol version, the clients could make first 
connection with v1.0.0, get the server version, close and reconnect identifying 
themselves at the same server version.

-Jake


On Jan 29, 2021, at 3:35 PM, Dan Smith 
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 
mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: 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 mailto:dasm...@vmware.com>>
Sent: Friday, January 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Bruce Schuchardt]

Oh, but I forgot about WAN changes that may have been made to the handshake to 
allow different versions in different clusters.  Jake might be right about this.

On 2/2/21, 8:31 AM, "Bruce Schuchardt"  wrote:

I think it's only the locator connections that do this.  Regular 
client->server connections using the handshake code just send the client's 
current version, which must not be newer than the server's version.

On 2/1/21, 9:53 AM, "Jacob Barrett"  wrote:

Having just spent some time yanking out some of the really really old 
version support I think a naive version knocking approach would work. During 
the client handshake the server will reject and close the connection of any 
client with a newer version number than it supports. The client could use this 
as signal to downgrade its version and try again. This could continue until the 
server accepts the client. We would need to decide if we would expect the 
entire membership to be a the same versions or if the version knocking needs to 
be on a per member basis. Obviously knocking for every connection is not ideal 
so some sort heuristic should be maintained for the life of the client.

Interestingly enough the clients sort of did this up until the merge of 
this version cleanups. All clients first made connections using the very old 
protocol version so that the server would send its version back. Then the 
client would disconnect and reconnect using its current version. The same could 
be done today with the current protocol version, the clients could make first 
connection with v1.0.0, get the server version, close and reconnect identifying 
themselves at the same server version.

-Jake


On Jan 29, 2021, at 3:35 PM, Dan Smith 
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 
mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: 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 mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: 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. 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Bruce Schuchardt]

One thing that might help somewhat would be to modify the KnownVersion class to 
hold both the product version and the client/server protocol version, which 
wouldn't have to change if there are no incompatibilities introduced in 
client/server comms in a release.  That's more in keeping with what Alberto is 
suggesting and is something we did in a past project (pre-Geode, pre-Pivotal) 
that never made it into the dev branch.

You could still have the downgrade behavior that Jake described but you 
wouldn't have to do it as often since, as Alberto pointed out, we rarely 
introduce incompatibilities these days.

In the case where the client/server protocol version hasn't changed but the 
client has a newer version than the server the client could use the server's 
older version for serialization.  The client would have to avoid using some 
client-side features added in its newer release, which I doubt would be an 
issue if we're just talking about rolling to a new version of Geode.

It's not the ideal world that Anthony envisions but it's a step that wouldn't 
take much work.

On 2/1/21, 9:27 AM, "Anthony Baker"  wrote:

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FNew%2BClient%2BServer%2BProtocoldata=04%7C01%7Cbruces%40vmware.com%7C87d10a873f5c4105ab6a08d8c6d696d2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477972248729037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hsWyivHYUmQhtortUac9qqJlqkgpuHzNIXM42Nlsg1Y%3Dreserved=0



On Jan 29, 2021, at 3:35 PM, Dan Smith 
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 mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: 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 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Bruce Schuchardt]

I think it's only the locator connections that do this.  Regular client->server 
connections using the handshake code just send the client's current version, 
which must not be newer than the server's version.

On 2/1/21, 9:53 AM, "Jacob Barrett"  wrote:

Having just spent some time yanking out some of the really really old 
version support I think a naive version knocking approach would work. During 
the client handshake the server will reject and close the connection of any 
client with a newer version number than it supports. The client could use this 
as signal to downgrade its version and try again. This could continue until the 
server accepts the client. We would need to decide if we would expect the 
entire membership to be a the same versions or if the version knocking needs to 
be on a per member basis. Obviously knocking for every connection is not ideal 
so some sort heuristic should be maintained for the life of the client.

Interestingly enough the clients sort of did this up until the merge of 
this version cleanups. All clients first made connections using the very old 
protocol version so that the server would send its version back. Then the 
client would disconnect and reconnect using its current version. The same could 
be done today with the current protocol version, the clients could make first 
connection with v1.0.0, get the server version, close and reconnect identifying 
themselves at the same server version.

-Jake


On Jan 29, 2021, at 3:35 PM, Dan Smith 
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 mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: 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 mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: 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 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Jacob Barrett]

Having just spent some time yanking out some of the really really old version 
support I think a naive version knocking approach would work. During the client 
handshake the server will reject and close the connection of any client with a 
newer version number than it supports. The client could use this as signal to 
downgrade its version and try again. This could continue until the server 
accepts the client. We would need to decide if we would expect the entire 
membership to be a the same versions or if the version knocking needs to be on 
a per member basis. Obviously knocking for every connection is not ideal so 
some sort heuristic should be maintained for the life of the client.

Interestingly enough the clients sort of did this up until the merge of this 
version cleanups. All clients first made connections using the very old 
protocol version so that the server would send its version back. Then the 
client would disconnect and reconnect using its current version. The same could 
be done today with the current protocol version, the clients could make first 
connection with v1.0.0, get the server version, close and reconnect identifying 
themselves at the same server version.

-Jake


On Jan 29, 2021, at 3:35 PM, Dan Smith 
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 mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: 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 mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: 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 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Anthony Baker]

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 
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 mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: 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 mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: 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.

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Dan Smith]

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 
Sent: Friday, January 29, 2021 11:40 AM
To: 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 
Sent: Friday, January 29, 2021 1:56 AM
To: 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 
Sent: Tuesday, January 26, 2021 6:45 AM
To: 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 
Sent: Friday, January 22, 2021 10:41 PM
To: 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 
Sent: Friday, 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Alberto Gomez]

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 
Sent: Friday, January 29, 2021 1:56 AM
To: 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 
Sent: Tuesday, January 26, 2021 6:45 AM
To: 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 
Sent: Friday, January 22, 2021 10:41 PM
To: 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 
Sent: Friday, January 22, 2021 8:35 PM
To: 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  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"
>
> 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Dan Smith]

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

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Alberto Gomez]

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 
Sent: Friday, January 22, 2021 10:41 PM
To: 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 
Sent: Friday, January 22, 2021 8:35 PM
To: 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  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%2Bserversdata=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3Dreserved=0
>
> Could you please provide feedback by Tuesday, February 2nd, 2021?
>
> Thanks,
>
> Alberto G.
>

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Alberto Gomez]

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 
Sent: Friday, January 22, 2021 8:35 PM
To: 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  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%2Bserversdata=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3Dreserved=0
>
> Could you please provide feedback by Tuesday, February 2nd, 2021?
>
> Thanks,
>
> Alberto G.
>

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Patrick Johnson]

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  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%2Bserversdata=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3Dreserved=0
> 
> Could you please provide feedback by Tuesday, February 2nd, 2021?
> 
> Thanks,
> 
> Alberto G.
>