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 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > 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 > extra parameters. > > Makes sense? > > D. > > On Tue, Aug 1, 2017 at 7:17 PM, Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > 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. > > > > New version of the protocol does not affect existing versions. > > > > On Tue, Aug 1, 2017 at 8:09 PM, <dsetrak...@apache.org> wrote: > > > > > Backward compatible? > > > > > > D. > > > > > > On Aug 1, 2017, 7:04 PM, at 7:04 PM, Pavel Tupitsyn < > > ptupit...@apache.org> > > > wrote: > > > >Dmitry, we don't need any reserved bytes, because protocol is > > > >versioned. > > > > > > > >On Tue, Aug 1, 2017 at 7:49 PM, <dsetrak...@apache.org> 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 > > > ><ptupit...@apache.org> > > > >> wrote: > > > >> >Alexey, good idea. ODBC and JDBC could also benefit from this. > > > >> > > > > >> >On Tue, Aug 1, 2017 at 7:27 PM, Alexey Kuznetsov > > > >> ><akuznet...@apache.org> > > > >> >wrote: > > > >> > > > > >> >> 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 > > > >> ><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 > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > > >> >> -- > > > >> >> Alexey Kuznetsov > > > >> >> > > > >> > > > > > >
