I think that in the first iteration it would be enough to have
connection-per-thread approach. But in future we definitely would like to
multiplex threads over a single connection and to support async operations.
That said, we definitely need request ID. Let's add it right now to avoid
compatibility issues in future.

On Wed, Aug 2, 2017 at 10:59 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> 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 <voze...@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 <yzhda...@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
> > >
> >
>

Reply via email to