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.a...@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.a...@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 > > > > > >
