You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geode.apache.org by Alberto Gomez <al...@est.tech> on 2021/01/22 19:05:39 UTC

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

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://cwiki.apache.org/confluence/display/GEODE/Add+option+to+allow+newer+Geode+clients+to+connect+to+older+Geode+servers

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

Posted by Alberto Gomez <al...@est.tech>.

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 <br...@vmware.com>
Sent: Tuesday, February 2, 2021 5:41 PM
To: dev@geode.apache.org <de...@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" <br...@vmware.com> 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" <ja...@vmware.com> 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 <da...@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 <al...@est.tech>>
        Sent: Friday, January 29, 2021 11:40 AM
        To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <da...@vmware.com>>
        Sent: Friday, January 29, 2021 1:56 AM
        To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
        Sent: Tuesday, January 26, 2021 6:45 AM
        To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
        Sent: Friday, January 22, 2021 10:41 PM
        To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <jp...@vmware.com>>
        Sent: Friday, January 22, 2021 8:35 PM
        To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@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&amp;data=04%7C01%7Cbruces%40vmware.com%7C70c9f8ebb7684cc8534508d8c6da39b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477987868254339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=F4BIW%2F%2BA8XiFY7QSmwr7Ue%2B1TYnWdrHebgIEeLV46Fw%3D&amp;reserved=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

Posted by Bruce Schuchardt <br...@vmware.com>.

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" <br...@vmware.com> 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" <ja...@vmware.com> 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 <da...@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 <al...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <da...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <jp...@vmware.com>>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@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&amp;data=04%7C01%7Cbruces%40vmware.com%7C70c9f8ebb7684cc8534508d8c6da39b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477987868254339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=F4BIW%2F%2BA8XiFY7QSmwr7Ue%2B1TYnWdrHebgIEeLV46Fw%3D&amp;reserved=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

Posted by Bruce Schuchardt <br...@vmware.com>.

On 2/1/21, 9:53 AM, "Jacob Barrett" <ja...@vmware.com> wrote:

-Jake

On Jan 29, 2021, at 3:35 PM, Dan Smith <da...@vmware.com>> wrote:

Hi Dan,

Thanks a lot for your comments.

Best regards,

This will require a lot of testing to make sure that users won't see strange corruption related errors related to serialization changes.

Hi,

I have updated the proposal in the RFC by adding Patrick's suggestion (if I have understood it correctly).

Best regards,

Thanks for your comments, Patrick.

Do you mean have the client always use in the handshake the oldest server version it is compatible with?

Alberto

On Jan 22, 2021, at 11:05 AM, Alberto Gomez <al...@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"

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

Posted by Jacob Barrett <ja...@vmware.com>.

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 <da...@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 <al...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <da...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <jp...@vmware.com>>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@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&amp;data=04%7C01%7Cjabarrett%40vmware.com%7Cb1958a42b97c408e38e708d8c4ae98a4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637475601469579270%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FJP7DlYM0n6I6FXWEgk1LgENYZ8ghyDzLieGxFJhKCQ%3D&amp;reserved=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

Posted by Bruce Schuchardt <br...@vmware.com>.

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" <ba...@vmware.com> 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%2BProtocol&amp;data=04%7C01%7Cbruces%40vmware.com%7C87d10a873f5c4105ab6a08d8c6d696d2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477972248729037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hsWyivHYUmQhtortUac9qqJlqkgpuHzNIXM42Nlsg1Y%3D&amp;reserved=0

On Jan 29, 2021, at 3:35 PM, Dan Smith <da...@vmware.com>> wrote:

Hi Dan,

Thanks a lot for your comments.

Best regards,

This will require a lot of testing to make sure that users won't see strange corruption related errors related to serialization changes.

Hi,

I have updated the proposal in the RFC by adding Patrick's suggestion (if I have understood it correctly).

Best regards,

Thanks for your comments, Patrick.

Do you mean have the client always use in the handshake the oldest server version it is compatible with?

Alberto

On Jan 22, 2021, at 11:05 AM, Alberto Gomez <al...@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&amp;data=04%7C01%7Cbruces%40vmware.com%7C87d10a873f5c4105ab6a08d8c6d696d2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477972248729037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cFdftflVsajfsgfej7nHkxSaWY%2F%2F4oJgrsglywFkSHQ%3D&amp;reserved=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

Posted by Anthony Baker <ba...@vmware.com>.

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 <da...@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 <al...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <da...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@est.tech>>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <jp...@vmware.com>>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@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 <al...@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&amp;data=04%7C01%7Cbakera%40vmware.com%7Cf1de5be28b6443dbf6cb08d8c4ae99be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637475601476402147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eDrJB6ZMKqdCKLlylpGWRA1M1t80OldT7o65jmggvWc%3D&amp;reserved=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

Posted by Dan Smith <da...@vmware.com>.

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 <al...@est.tech>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org <de...@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 <da...@vmware.com>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org <de...@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 <al...@est.tech>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org <de...@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 <al...@est.tech>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org <de...@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 <jp...@vmware.com>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org <de...@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 <al...@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&amp;data=04%7C01%7Cdasmith%40vmware.com%7Cbc5745457bb94475fc1e08d8c48db9f7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637475460278858460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mIIVzsfqMFfsaM9Et9emxBgBfcfJyDCWVvPrIB0NUxo%3D&amp;reserved=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

Posted by Alberto Gomez <al...@est.tech>.

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 <da...@vmware.com>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org <de...@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 <al...@est.tech>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org <de...@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 <al...@est.tech>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org <de...@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 <jp...@vmware.com>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org <de...@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 <al...@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&amp;data=04%7C01%7Cdasmith%40vmware.com%7C776eddfeec43423ccfee08d8c2091d4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637472691702967826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jRf5gJ7UIlCnrK%2FLfH6fSg1yLtb3%2BMdc3krwkOvtJA0%3D&amp;reserved=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

Posted by Dan Smith <da...@vmware.com>.

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 <al...@est.tech>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org <de...@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 <al...@est.tech>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org <de...@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 <jp...@vmware.com>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org <de...@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 <al...@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&amp;data=04%7C01%7Cdasmith%40vmware.com%7C776eddfeec43423ccfee08d8c2091d4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637472691702967826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jRf5gJ7UIlCnrK%2FLfH6fSg1yLtb3%2BMdc3krwkOvtJA0%3D&amp;reserved=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

Posted by Alberto Gomez <al...@est.tech>.

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 <al...@est.tech>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org <de...@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 <jp...@vmware.com>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org <de...@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 <al...@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&amp;data=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3D&amp;reserved=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

Posted by Alberto Gomez <al...@est.tech>.

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 <jp...@vmware.com>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org <de...@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 <al...@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&amp;data=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3D&amp;reserved=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

Posted by Patrick Johnson <jp...@vmware.com>.

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 <al...@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&amp;data=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3D&amp;reserved=0
> 
> Could you please provide feedback by Tuesday, February 2nd, 2021?
> 
> Thanks,
> 
> Alberto G.
>