Re: Thin client protocol message format

The concern has been solved after I had a swift private conversation with Vladimir Ozerov. We just need to document how to write and read all the types supported by binary format. That’s more than enough for the beginning. — Denis > On Nov 17, 2017, at 10:40 AM, Denis Magda

Re: Thin client protocol message format

Igniters, Let me reiterate on the protocol details until it becomes publicly available. If I’m not mistaken one of the reasons we got down to this task was to give an efficient low-level protocol that will simplify and boost Ignite clients/connectors development for various programming

Re: Thin client protocol message format

Got it, thanks! On Aug 3, 2017, 11:04 AM, at 11:04 AM, Vladimir Ozerov wrote: >Dima, > >Our goal is to have a format, which will work for both synchronous, >asynchronous, single-threaded and multi-threaded clients. All we need >to >achieve this is "request ID" propagated

Re: Thin client protocol message format

Dima, Our goal is to have a format, which will work for both synchronous, asynchronous, single-threaded and multi-threaded clients. All we need to achieve this is "request ID" propagated from request to response. This way 3-rd party developers will be free to decide how to implement the client.

Re: Thin client protocol message format

Let us not forget that the main purpose of such protocol is to enable other users contribute their own client implementations for various languages. Also, most JDBC and ODBC use cases work in thread-per-connection mode. I think that if we introduce a multi-threaded client here, then it will be a

Re: Thin client protocol message format

Yakov, >This should be set up in handshake and used for all requests made over that connection. Sounds reasonable. On Wed, Aug 2, 2017 at 6:29 PM, Yakov Zhdanov wrote: > > Response should contains Node ID that send response to thin client. > > This should be set up in

Re: Thin client protocol message format

> Response should contains Node ID that send response to thin client. This should be set up in handshake and used for all requests made over that connection. --Yakov 2017-08-02 14:12 GMT+03:00 Alexey Kuznetsov : > Pavel, > > I remember one thing that is very useful for

Re: Thin client protocol message format

Pavel, 2. Disagree here. In your sample responses contain only success flag which is byte and 4 bytes length. We can easily avoid that just sending OP_CODE_SUCCESS or OP_CODE_FAILURE. 3. In and out where applicable. --Yakov

Re: Thin client protocol message format

Pavel, I do not see how it can effect something existing, as nothing exists yet :-) Let's put current SQL aside, we will merge them into protocol later. The main point of length is to move request parsing and deserialization to separate thread. Without it we will have to pre-process all requests

Re: Thin client protocol message format

Yakov, > 2. put op_code to the first place. This will make possible to eliminate length field for many messages This will require extensive refactoring of existing socket pipeline for very little benefit: almost all messages are of variable length. > 3. build date and revision hash to handshake

Re: Thin client protocol message format

Agree with Alex. I think our implementations should share single connection over threads in the process. --Yakov

Re: Thin client protocol message format

I think that in the first iteration it would be enough to have connection-per-thread approach. But in future we definitely would like to multiplex threads over a single connection and to support async operations. That said, we definitely need request ID. Let's add it right now to avoid

Re: Thin client protocol message format

Do I understand correctly that this is not a multiplexed protocol? Are we ok to have a separate connection for each thread? I would also add a requestId field to allow multiple concurrent requests at a time. 2017-08-02 10:50 GMT+03:00 Vladimir Ozerov : > Yakov, > > Yes,

Re: Thin client protocol message format

Here are my observations. 1. Let's create wiki page where we will keep the protocol definition and reflect all the changes. 2. I would put op_code to the first place. This will make possible to eliminate length field for many messages. Look at your handshake request - it is always of fixed

Re: Thin client protocol message format

Dima, There is no need for these extra bytes. Protocol version would be enough. Extensibility points wil be designed separately. We already have experience with it in scope of .NET/CPP platforms, it is solved by special command types where user can hook his own code. On Wed, Aug 2, 2017 at 3:56

Re: Thin client protocol message format

How about allowing 8 bytes of extra space for any user-specific additional data? For example, I can see that some implementations of this protocol will need to pass some extra parameters to the server. Of course, in that case the server side protocol handler should have a hook to react to these

Re: Thin client protocol message format

Yes, in my understanding, we should provide backwards compatibility via versioning. During handshake we pick RequestParser and RequestHandler (this is already implemented, see SqlListenerNioListener.prepareContext). Each protocol version would have separate implementations of these interfaces.

Re: Thin client protocol message format

Backward compatible? ⁣D.​ On Aug 1, 2017, 7:04 PM, at 7:04 PM, Pavel Tupitsyn wrote: >Dmitry, we don't need any reserved bytes, because protocol is >versioned. > >On Tue, Aug 1, 2017 at 7:49 PM, wrote: > >> We should also leave 8 bytes of empty

Re: Thin client protocol message format

Dmitry, we don't need any reserved bytes, because protocol is versioned. On Tue, Aug 1, 2017 at 7:49 PM, wrote: > We should also leave 8 bytes of empty space for future changes. > > ⁣D.​ > > On Aug 1, 2017, 6:41 PM, at 6:41 PM, Pavel Tupitsyn >

Re: Thin client protocol message format

We should also leave 8 bytes of empty space for future changes. ⁣D.​ On Aug 1, 2017, 6:41 PM, at 6:41 PM, Pavel Tupitsyn wrote: >Alexey, good idea. ODBC and JDBC could also benefit from this. > >On Tue, Aug 1, 2017 at 7:27 PM, Alexey Kuznetsov >

Re: Thin client protocol message format

Alexey, good idea. ODBC and JDBC could also benefit from this. On Tue, Aug 1, 2017 at 7:27 PM, Alexey Kuznetsov wrote: > Pavel, > > How about data compression? > May be it make sense to add a byte with compression algorithm? > 0 - none > 1 - ZIP > 2 - > > > On

Re: Thin client protocol message format

For supporting different cases, might be useful to add to handshake message one byte for different flags. compression is a good example. Also it can be some specific logic for different clients (C++, JS, Python), crypting and etc. On Tue, Aug 1, 2017 at 7:27 PM, Alexey Kuznetsov

Re: Thin client protocol message format

Pavel, How about data compression? May be it make sense to add a byte with compression algorithm? 0 - none 1 - ZIP 2 - On Tue, Aug 1, 2017 at 11:10 PM, Pavel Tupitsyn wrote: > Igniters, > > Below is a proposed design for thin client protocol [1] [2] socket data