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