ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Thin client protocol message format
Date Wed, 02 Aug 2017 07:59:06 GMT
Do I understand correctly that this is not a multiplexed protocol? Are we
ok to have a separate connection for each thread? I would also add a
requestId field to allow multiple concurrent requests at a time.

2017-08-02 10:50 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:

> Yakov,
>
> Yes, explicit protocol versioning already used in ODBC/JDBC. Looks like we
> should continue this practice in this protocol as well.
>
> On Wed, Aug 2, 2017 at 10:44 AM, Yakov Zhdanov <yzhdanov@apache.org>
> wrote:
>
> > Here are my observations.
> >
> > 1. Let's create wiki page where we will keep the protocol definition and
> > reflect all the changes.
> >
> > 2. I would put op_code to the first place. This will make possible to
> > eliminate length field for many messages. Look at your handshake request
> -
> > it is always of fixed length. Why do we need length then? Variable length
> > operations - puts, putalls, getalls, etc will definitely need length
> field
> > (or keys count and length of each key separately in each binary object -
> > let's discuss it later).
> >
> > 3. I would also add build date and revision hash to handshake. Same as we
> > do for Ignite.
> >
> > 4. I would like to have explicit protocol version for client to make
> > possible for newer clients to work with older servers. Moreover, I think
> > there may be some third party protocol implementations on other platforms
> > which may not be driven by Ignite community and their versioning may be
> > different. So, explicit protocol version is really handy here.
> >
> > Thanks!
> >
> > --Yakov
> >
>

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