You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bruce Schuchardt <br...@vmware.com> on 2021/02/23 17:38:03 UTC

[DISCUSS] client/server communications and versioning

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

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

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

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

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

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

Re: [DISCUSS] client/server communications and versioning

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

This proposal makes a lot of sense.

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

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

BR,

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

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

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

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

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

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

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

Re: [DISCUSS] client/server communications and versioning

Posted by Bruce Schuchardt <br...@vmware.com>.
Yes, if we change the client/server protocol version in a patch release we'll have to update newer releases to know about it.  I don't recall that happening much over the years, though.  We used to guarantee there would be no on-wire incompatibilities for clients in patch releases, didn't we?

To your other question about complexity, Dan pointed out the most difficult thing this would add to the mix: knowing when you may need to bump the protocol version.  I think that the savings in time for us (putting out unnecessary patches for newer releases) and customers (not having to install those new patch releases) would make it worth our effort.

On 2/23/21, 2:36 PM, "Anilkumar Gingade" <ag...@vmware.com> wrote:

    Bruce,
    >> To solve that problem we currently have to issue a new 1.13 release that knows about v1.12.1 and users have to roll their servers to the new v1.13.1.
    Even if we introduce the client protocol version, the users still need to upgrade to server version, that understands the protocol right? E.g. 1.13 may not understand 1.8.1 (or 1.9) protocol.

    Also, currently we have client and server versions; this will introduce one more versioning requirement (with respect to client/server messaging protocol); I am just wondering will there be any additional work/complexities in knowing, maintaining client/server version and the messaging protocol version with them... 

    -Anil.

    On 2/23/21, 1:56 PM, "Dan Smith" <da...@vmware.com> wrote:

        Ha, I was thinking of suggesting this when I saw Alberto's earlier proposal. This does seem like a good idea to only bump the client version when the protocol actually changes.

        One concern is that it might not be obvious that changing a DataSerializableFixedId will change the client protocol. Some objects get sent or received from the client and some don't, but we don't have a clear indication which is which. Is there some way that we could know when changing a DataSerializableFixedId if it is involved in the client protocol or not?

        I also wonder if this will affect the WAN - do we want to keep sending the current product version with the WAN, or use the client protocol version?

        -Dan
        ________________________________
        From: Bruce Schuchardt <br...@vmware.com>
        Sent: Tuesday, February 23, 2021 9:38 AM
        To: dev@geode.apache.org <de...@geode.apache.org>
        Subject: [DISCUSS] client/server communications and versioning

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

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

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

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

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

        See https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&amp;data=04%7C01%7Cbruces%40vmware.com%7Cf128c07ec2be4dd15dea08d8d84b6d99%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497165768458585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TgxtjFz4RR6KaSi0uC2khANsLv3XRBD4pme28r1zMjM%3D&amp;reserved=0

Re: [DISCUSS] client/server communications and versioning

Posted by Anilkumar Gingade <ag...@vmware.com>.
Bruce,
>> To solve that problem we currently have to issue a new 1.13 release that knows about v1.12.1 and users have to roll their servers to the new v1.13.1.
Even if we introduce the client protocol version, the users still need to upgrade to server version, that understands the protocol right? E.g. 1.13 may not understand 1.8.1 (or 1.9) protocol.

Also, currently we have client and server versions; this will introduce one more versioning requirement (with respect to client/server messaging protocol); I am just wondering will there be any additional work/complexities in knowing, maintaining client/server version and the messaging protocol version with them... 

-Anil.

On 2/23/21, 1:56 PM, "Dan Smith" <da...@vmware.com> wrote:

    Ha, I was thinking of suggesting this when I saw Alberto's earlier proposal. This does seem like a good idea to only bump the client version when the protocol actually changes.

    One concern is that it might not be obvious that changing a DataSerializableFixedId will change the client protocol. Some objects get sent or received from the client and some don't, but we don't have a clear indication which is which. Is there some way that we could know when changing a DataSerializableFixedId if it is involved in the client protocol or not?

    I also wonder if this will affect the WAN - do we want to keep sending the current product version with the WAN, or use the client protocol version?

    -Dan
    ________________________________
    From: Bruce Schuchardt <br...@vmware.com>
    Sent: Tuesday, February 23, 2021 9:38 AM
    To: dev@geode.apache.org <de...@geode.apache.org>
    Subject: [DISCUSS] client/server communications and versioning

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

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

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

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

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

    See https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&amp;data=04%7C01%7Cagingade%40vmware.com%7Cb2798fe5be1a401bfa5708d8d845ea70%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637497142090368767%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9Tr2x%2BWD3s43TvoQNtsyqW0rwhNU5GOK8PxxEjw1mb8%3D&amp;reserved=0

Re: [DISCUSS] client/server communications and versioning

Posted by Bruce Schuchardt <br...@vmware.com>.
I was worrying about DSFID changes, too, but I think we'll know if we need the updated data in the client.  What might be surprising to people is if they make a change and don't see it getting to the client because it's using an old version.  If I add a field to a DSFID and update toData to include it I would also add a toData_pre_xyz method and that's what would be used to serialize the value to the client.

On 2/23/21, 1:56 PM, "Dan Smith" <da...@vmware.com> wrote:

    Ha, I was thinking of suggesting this when I saw Alberto's earlier proposal. This does seem like a good idea to only bump the client version when the protocol actually changes.

    One concern is that it might not be obvious that changing a DataSerializableFixedId will change the client protocol. Some objects get sent or received from the client and some don't, but we don't have a clear indication which is which. Is there some way that we could know when changing a DataSerializableFixedId if it is involved in the client protocol or not?

    I also wonder if this will affect the WAN - do we want to keep sending the current product version with the WAN, or use the client protocol version?

    -Dan
    ________________________________
    From: Bruce Schuchardt <br...@vmware.com>
    Sent: Tuesday, February 23, 2021 9:38 AM
    To: dev@geode.apache.org <de...@geode.apache.org>
    Subject: [DISCUSS] client/server communications and versioning

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

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

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

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

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

    See https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&amp;data=04%7C01%7Cbruces%40vmware.com%7Cc94da0c3d72940da384108d8d845ecea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497142136344324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=l9Vvk86DrwMYls6XViSu8bKgdhJpPCc3mSosFBCngX0%3D&amp;reserved=0

Re: [DISCUSS] client/server communications and versioning

Posted by Dan Smith <da...@vmware.com>.
Ha, I was thinking of suggesting this when I saw Alberto's earlier proposal. This does seem like a good idea to only bump the client version when the protocol actually changes.

One concern is that it might not be obvious that changing a DataSerializableFixedId will change the client protocol. Some objects get sent or received from the client and some don't, but we don't have a clear indication which is which. Is there some way that we could know when changing a DataSerializableFixedId if it is involved in the client protocol or not?

I also wonder if this will affect the WAN - do we want to keep sending the current product version with the WAN, or use the client protocol version?

-Dan
________________________________
From: Bruce Schuchardt <br...@vmware.com>
Sent: Tuesday, February 23, 2021 9:38 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [DISCUSS] client/server communications and versioning

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

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

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

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

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

See https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&amp;data=04%7C01%7Cdasmith%40vmware.com%7C5b110c0f33d54702ebea08d8d821cfc1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637496987021268228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QplNcKl9wRM5R6RL9V2oLHUiYkur9214NcApA%2Bfhxfg%3D&amp;reserved=0

Re: [DISCUSS] client/server communications and versioning

Posted by Owen Nichols <on...@vmware.com>.
Sounds reasonable.  We increment the serialization version every minor release "just in case" anything has changed in the server-to-server protocol, but client-to-server should change a lot less frequently, as you pointed out.

Now that Geode is maintaining support branches with longer life, rather that our old model of releasing new minors linearly every 3 months and patch releases hardly ever, there is increased likelihood of getting into a situation where a newer patch on an older minor could increment the server-to-server serialization version, and it would be great if this didn't unnecessarily break clients.

On 2/23/21, 9:38 AM, "Bruce Schuchardt" <br...@vmware.com> wrote:

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

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

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

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

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

    See https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&amp;data=04%7C01%7Conichols%40vmware.com%7C450f013015004deac5e308d8d821cc7f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637496986983812499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=l4QPnp1D2nEK0G%2FI%2FhZ3UJ9PEDP2CDaJRWd3I6BISe0%3D&amp;reserved=0