ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Thin Client Protocol documentation
Date Fri, 01 Dec 2017 13:48:32 GMT
There are no legacy formats. JDBC and ODBC clients are not "legacy", quite
the opposite.

In future we may even want to combine JDBC Thin and general-purpose Thin
clients since they have a lot in common.
So let's keep the handshake format consistent across clients.

> exceptions for message formats
Handshake is an exception anyway, it does not have (or need) requestId, etc.

On Fri, Dec 1, 2017 at 1:38 PM, Alexey Popov <tank2.alex@gmail.com> wrote:

> Pavel,
>
> I believe ClientListenerNioListener.onHandshake() could support more than
> one Handshake request format (be backward compatible), for instance, if we
> will have a new handshake code = 0xABCD that differs from 0x01 byte.
>
> It is a design vs architecture question.
>
> I can’t understand why the legacy Handshake format should be used for a
> new protocol. If this protocol is supposed to be public it should have no
> exceptions for message formats.
>
> Thank you,
> Alexey
>
> From: Pavel Tupitsyn
> Sent: Thursday, November 30, 2017 12:11 PM
> To: dev@ignite.apache.org
> Subject: Re: Thin Client Protocol documentation
>
> Hi Alexey,
>
> 1,2,3 are related only to handshake. All other operations are consistent.
>
> Handshake request format is dictated by existing client connector that is
> shared with ODBC and JDBC clients (see
> ClientListenerNioListener.onHandshake).
> so we can't add magic numbers or change operation code.
>
> But yes, we can add server version to the handshake response, and I think
> this makes sense.
>
> > 4. The same comments for success flag (1 byte) and status code (4 bytes)
> in responses. Let's leave only status code.
> We don't have a success flag in responses, there is just a 4-byte status
> code, 0 indicates success, everything else is an error.
>
> Thanks,
> Pavel
>
> On Thu, Nov 30, 2017 at 12:01 PM, Alexey Popov <tank2.alex@gmail.com>
> wrote:
>
> > Hi Pavel,
> >
> > Let me add my 5 cents.
> >
> > 1. It would be great if both Handshake request & response have some
> > "magic" number (2 or 4 bytes) inside their msg body. That will simplify
> > handling situations when non-Ignite client connects to Ignite server and
> > vice versa.
> >
> > 2. It makes sense to add server version to successful Handshake response
> > as well. It will help to understand & debug possible backward
> compatibility
> > issues in the field by *.pcap logs analysis & etc.
> >
> > 3. Can we have a more strict header for all message types?
> > As far as I understand,
> > Handshake request has:
> > 1) length - 4 byte
> > 2) Handshake code - 1 byte
> > 3) body - (length - 1) bytes
> >
> > while OP_CACHE_GET request has:
> > 1) length - 4 byte
> > 2) OP_CACHE_GET code - 2 bytes
> > 3) request id - 4 bytes
> > 4) body - (length - 2 - 4) bytes
> >
> > Why some messages have Operation code with 1 byte while others - 2 bytes?
> > Why some requests/responses have request-id while others don't? Let's
> > simplify parser work )
> >
> > 4. The same comments for success flag (1 byte) and status code (4 bytes)
> > in responses. Let's leave only status code.
> >
> > Thank you,
> > Alexey
> >
> > From: Pavel Tupitsyn
> > Sent: Wednesday, November 22, 2017 4:04 PM
> > To: dev@ignite.apache.org
> > Subject: Thin Client Protocol documentation
> >
> > Igniters,
> >
> > I've put together a detailed description of our Thin Client protocol
> > in form of IEP on wiki:
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 9+Thin+Client+Protocol
> >
> >
> > To clarify:
> > - Protocol implementation is in master (see ClientMessageParser class)
> > - Protocol has not been released yet, so we are free to change anything
> > - Protocol is only used by .NET Thin Client for now, but is supposed to
> be
> > used from other languages by third party contributors
> > - More operations will be added in future, this is a first set of them,
> > cache-related
> >
> >
> > Please review the document and let me know your thoughts.
> > Is there anything missing or wrong?
> >
> > We should make sure that the foundation is solid and extensible.
> >
> >
> > Thanks,
> > Pavel
> >
> >
>
>

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