ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Thin client protocol message format
Date Wed, 02 Aug 2017 05:55:49 GMT
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 <dsetrakyan@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 <ptupitsyn@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, <dsetrakyan@apache.org> wrote:
> >
> > > Backward compatible?
> > >
> > > ⁣D.​
> > >
> > > On Aug 1, 2017, 7:04 PM, at 7:04 PM, Pavel Tupitsyn <
> > ptupitsyn@apache.org>
> > > wrote:
> > > >Dmitry, we don't need any reserved bytes, because protocol is
> > > >versioned.
> > > >
> > > >On Tue, Aug 1, 2017 at 7:49 PM, <dsetrakyan@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
> > > ><ptupitsyn@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
> > > >> ><akuznetsov@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
> > > >> ><ptupitsyn@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
> > > >> >>
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message