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" <jabarr...@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
<dasm...@vmware.com<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 <alberto.go...@est.tech<mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org>
<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 <dasm...@vmware.com<mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org>
<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.
-Dan
________________________________
From: Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>>
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org>
<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,
I have updated the proposal in the RFC by adding Patrick's suggestion (if I
have understood it correctly).
Best regards,
Alberto
________________________________
From: Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>>
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org>
<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
Thanks for your comments, Patrick.
Do you mean have the client always use in the handshake the oldest server
version it is compatible with?
Sounds like a reasonable simplification. In that case, I would use a flag
to activate this behavior so that the current behavior (the client sends the
current version in the handshake) is kept when the flag is not used.
On the other hand if in the future we have clients that are partially
compatible with an older server version, the System Property with the version
could allow these clients to connect to that server version assuming that they
will not use any incompatible feature.
Alberto
________________________________
From: Patrick Johnson <jpatr...@vmware.com<mailto:jpatr...@vmware.com>>
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org>
<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
It sounds like you intend to test which versions are compatible with each
other and maintain a list the client can use to reject the setting of
force-version when set to an incompatible version. If that’s the case, why not
just have the handshake look at that list and automatically connect with any
versions that it is known to be compatible with? Then you wouldn’t even have to
set the property.
On Jan 22, 2021, at 11:05 AM, Alberto Gomez
<alberto.go...@est.tech<mailto:alberto.go...@est.tech>> wrote:
Hi Geode devs,
I have just published the following RFC in the Geode wiki: "Add option to
allow newer Geode clients to connect to older Geode servers"
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2Boption%2Bto%2Ballow%2Bnewer%2BGeode%2Bclients%2Bto%2Bconnect%2Bto%2Bolder%2BGeode%2Bservers&data=04%7C01%7Cbruces%40vmware.com%7C70c9f8ebb7684cc8534508d8c6da39b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637477987868254339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F4BIW%2F%2BA8XiFY7QSmwr7Ue%2B1TYnWdrHebgIEeLV46Fw%3D&reserved=0
Could you please provide feedback by Tuesday, February 2nd, 2021?
Thanks,
Alberto G.
