ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sapego <isap...@apache.org>
Subject Re: Binary clients: fallback to the previous versions of the protocol
Date Tue, 12 Feb 2019 10:39:16 GMT
Hi,

Well, this approach was used for quite some time in ODBC and JDBC,
so thin client has just inherited it, as we have the same port and the
same handshake message header. Maybe that's why you could not find
any mention of versioning in thin client context.

3. Let's start from this point as this is the root of the issue.
Preconditions
are simple - the backward compatibility. We should guarantee that user
can use any version of thin client with any version of server while they
share the same major version. This can be important, if someone have
user applications built with thin client and they don't want to break their
user applications, when they just want to update servers. What is
appropriate here is to give user some kind of warning that they use
outdated client or server.

Can you explain how your approach is going to work in the example
above? I'm not quite sure I understand you correctly.

1. The API for this can be as simple as a set of allowed version in
a configuration for both server and client. Maybe we should discuss such
kind of API as it can be useful for example in terms of security.

2. Complexity is the price developers have to pay for better user
experience.
Nothing new here. Software is not designed for developers, it's designed
for a user.

Best Regards,
Igor


On Tue, Feb 12, 2019 at 11:56 AM Dmitry Melnichuk <
dmitry.melnichuk@nobitlost.com> wrote:

> Hello fellow igniters!
>
> I recently started reconnaissance before the
> implementation of IEP-23 [1] in Python thin client. I think it is an
> interesting and much promising feature. As I understand, the changes
> associated with this feature will result in a new version of the binary
> protocol.
>
> What bothers me is not the changes required by the
> implementation itself, but the upcoming changes in the way that the
> fallback to the previous versions of the protocol is going to be
> handled.
>
> I have not found a open discussion on this topic neither on
> this mailing list, nor in Jira. If such a discussion took place, please
> inform me with a link. Based on what I have heard so far, I made the
> following conclusions:
>
> 1) the client is now expected to handle multiple
> binary protocol versions;
> 2) since the protocol is implemented the way
> the client first reports its version to the server on handshake, and
> not the other way, the client now must try to connect to the server
> using its preferred version of the protocol, and in case of an error,
> reconnect with another version.
>
> These changes are raised some concerns
> for me, for example:
>
> 1) the version negotiation mechanism implemented on
> client can not be made transparent to the end user. We must give the
> user an option, so that they could choose from the entire set of
> versions supported by the client, a subset of the versions their
> application is designed to work with. That will complicate the user
> API;
>
> 2) the complexity of the client will also be increased, especially
> considering unit testing. Certain tests will require a certain version
> of Ignite server, so they can no longer be implemented environment-
> agnostically, leading to a weird mix on unit and integration levels;
>
> 3)
> I do not see, or not aware of, the preconditions to such changes. I
> think the number of potential applications that can benefit from multi-
> protocol client is quite low. Usually all the hassle of version
> matching lie on the deployment level, above the app level. Please prove
> me wrong on this subject.
>
> Instead of supporting multiple binary
> protocols inside one client package, I would strongly prefer to support
> each version of the protocol separately, in the corresponding branch of
> the package repository. It would still be possible for the end user to
> use multiple protocols in one app, but with certain code-level and
> deployment-level efforts combined.
>
> Again, I most probably lack awareness
> on the subject, and therefore my conclusions may be premature, but
> anyway, let us discuss. I will appreciate any bit of knowledge from the
> community.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 23:+Best+Effort+Affinity+for+thin+clients
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message