Thin client protocol message format

[Alexey Kuznetsov]

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 <[hidden email]> wrote:

> >  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 <[hidden email]>:
>
> > Pavel,
> >
> > I remember one thing that is very useful for thing client:
> >   Response should contains Node ID that send response to thin client.
> >
> > This can be used for debugging needs.
> >
> > On Wed, Aug 2, 2017 at 4:10 PM, Yakov Zhdanov <[hidden email]>
> wrote:
> >
> > > 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
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>

--
Alexey Kuznetsov

[dsetrakyan]

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 lot harder to understand, configure, use, or contribute, so I agree with
Vladimir.

Let's keep it simple for now.

D.

On Wed, Aug 2, 2017 at 10:37 AM, Yakov Zhdanov <[hidden email]> wrote:

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

[Vladimir Ozerov]

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.

On Thu, Aug 3, 2017 at 4:52 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> 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 lot harder to understand, configure, use, or contribute, so I agree with
> Vladimir.
>
> Let's keep it simple for now.
>
> D.
>
> On Wed, Aug 2, 2017 at 10:37 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Agree with Alex. I think our implementations should share single
> connection
> > over threads in the process.
> >
> > --Yakov
> >
>

[dsetrakyan]

Got it, thanks!

On Aug 3, 2017, 11:04 AM, at 11:04 AM, Vladimir Ozerov <[hidden email]> 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 from request to response. This
>way
>3-rd party developers will be free to decide how to implement the
>client.
>
>On Thu, Aug 3, 2017 at 4:52 AM, Dmitriy Setrakyan
><[hidden email]>
>wrote:
>
>> 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 lot harder to understand, configure, use, or contribute, so I agree
>with
>> Vladimir.
>>
>> Let's keep it simple for now.
>>
>> D.
>>
>> On Wed, Aug 2, 2017 at 10:37 AM, Yakov Zhdanov <[hidden email]>
>> wrote:
>>
>> > Agree with Alex. I think our implementations should share single
>> connection
>> > over threads in the process.
>> >
>> > --Yakov
>> >
>>

[dmagda]

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 languages *avoiding* any Ignite related dependancies such as binary marshaller.

However, by some reason we agreed to stick to the binary marshaller:
> * Ignite binary format is used for value serialization (via
> GridBinaryMarshaller/BinaryWriter/BinaryReader). Ignite binary protocol has
> to be implemented by clients anyway to work with cache values, so it makes
> sense to use for all data exchange.

This suggests me that if a developer wants to exchange messages with the cluster from Python, Node.js, Objective-C, embedded hardware such as smart meters being power by real-time operating systems he/she has to support the binary marshaller first. This sounds like a bar for the protocol adoption.

Question:

- What exactly has to be supported on the binary protocol side?
- Any concerns on why we can’t switch to widely used format such as JSON?

—
Denis

> On Aug 1, 2017, at 9:10 AM, Pavel Tupitsyn <[hidden email]> wrote:
>
> Igniters,
>
> Below is a proposed design for thin client protocol [1] [2] socket data
> exchange format.
>
> * Values are little-endian
> * Every request and response message starts with 4-byte length (including
> handshake)
> * Ignite binary format is used for value serialization (via
> GridBinaryMarshaller/BinaryWriter/BinaryReader). Ignite binary protocol has
> to be implemented by clients anyway to work with cache values, so it makes
> sense to use for all data exchange.
>
>
> 1) Socket connection is established on a port according
> to ConnectorConfiguration.port
>
> 2) Handshake is performed.
> Request:
>   int32 length = 8     // message length
>   byte opCode = 1   // handshake command
>   int16 verMajor
>   int16 verMinor
>   int16 verMaintenance
>   byte clientCode = 2    // client type code (odbc, jdbc, platform)
>
> Response:
>   uint32 length = 1
>   byte success
>
> 3) Execute command. Request starts with a command code, then goes
> command-specific data.
> For example, IgniteCache<Integer, String>.put(1, "foo") will look like this:
> Request:
>   int16 opCode    // OP_CACHE_GET
>   int32 cacheId    // GridCacheUtils.cacheId
>   byte flags          // skipStore, noRetry, etc
>   binobject key
>
> Response:
>   byte success
>   binobject value
>
> Where binobject corresponds to Ignite BinaryMarshaller format, which is
> produced by BinaryWriter.writeObject method. Integer will be represented as
>  byte typeCode = 3  // GridBinaryMarshaller.INT
>  int32 value = 1
>
> 4) Goto (3)
>
>
> Comments are welcome.
>
> Pavel
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Support-for-Ignite-clients-in-any-language-thin-client-protocol-td20297.html
> [2] https://issues.apache.org/jira/browse/IGNITE-5896

[dmagda]

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 <[hidden email]> wrote:
>
> 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 languages *avoiding* any Ignite related dependancies such as binary marshaller.
>
> However, by some reason we agreed to stick to the binary marshaller:
>> * Ignite binary format is used for value serialization (via
>> GridBinaryMarshaller/BinaryWriter/BinaryReader). Ignite binary protocol has
>> to be implemented by clients anyway to work with cache values, so it makes
>> sense to use for all data exchange.
>
> This suggests me that if a developer wants to exchange messages with the cluster from Python, Node.js, Objective-C, embedded hardware such as smart meters being power by real-time operating systems he/she has to support the binary marshaller first. This sounds like a bar for the protocol adoption.
>
> Question:
>
> - What exactly has to be supported on the binary protocol side?
> - Any concerns on why we can’t switch to widely used format such as JSON?
>
> —
> Denis
>
>
>> On Aug 1, 2017, at 9:10 AM, Pavel Tupitsyn <[hidden email]> wrote:
>>
>> Igniters,
>>
>> Below is a proposed design for thin client protocol [1] [2] socket data
>> exchange format.
>>
>> * Values are little-endian
>> * Every request and response message starts with 4-byte length (including
>> handshake)
>> * Ignite binary format is used for value serialization (via
>> GridBinaryMarshaller/BinaryWriter/BinaryReader). Ignite binary protocol has
>> to be implemented by clients anyway to work with cache values, so it makes
>> sense to use for all data exchange.
>>
>>
>> 1) Socket connection is established on a port according
>> to ConnectorConfiguration.port
>>
>> 2) Handshake is performed.
>> Request:
>>  int32 length = 8     // message length
>>  byte opCode = 1   // handshake command
>>  int16 verMajor
>>  int16 verMinor
>>  int16 verMaintenance
>>  byte clientCode = 2    // client type code (odbc, jdbc, platform)
>>
>> Response:
>>  uint32 length = 1
>>  byte success
>>
>> 3) Execute command. Request starts with a command code, then goes
>> command-specific data.
>> For example, IgniteCache<Integer, String>.put(1, "foo") will look like this:
>> Request:
>>  int16 opCode    // OP_CACHE_GET
>>  int32 cacheId    // GridCacheUtils.cacheId
>>  byte flags          // skipStore, noRetry, etc
>>  binobject key
>>
>> Response:
>>  byte success
>>  binobject value
>>
>> Where binobject corresponds to Ignite BinaryMarshaller format, which is
>> produced by BinaryWriter.writeObject method. Integer will be represented as
>> byte typeCode = 3  // GridBinaryMarshaller.INT
>> int32 value = 1
>>
>> 4) Goto (3)
>>
>>
>> Comments are welcome.
>>
>> Pavel
>>
>> [1]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Support-for-Ignite-clients-in-any-language-thin-client-protocol-td20297.html
>> [2] https://issues.apache.org/jira/browse/IGNITE-5896
>