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 <ptupit...@apache.org> 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
