Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGt6o8k=GiH8k2=2kAHTkArc8QY+vMf3-Wvd-ttd8m1R+PxQbg@mail.gmail.com>
References: <CAK2_iMNYmGqsWPz1DDMNuOiOhhDyYf0Ak5cZG-Utxt3E6c9NYg@mail.gmail.com>
 <CALH+G9oJfQoJ4+y7C8yH8ymp6k4mM2Jj-mE5=Fm8LJ=pAwx3EQ@mail.gmail.com>
 <CAK2_iMNWqO4FydiCbebFgxppTMBn5gxBpu_qjJeZDcU13C6gJg@mail.gmail.com>
 <c19d0184-8a7e-4199-903e-4499d9f7b486@apache.org> <CAK2_iMPKwVe_5d-2VV=YcDjriJ3QYn46=rxmMHeZM9hDC4oHXA@mail.gmail.com>
 <e369ea9b-7e0b-4d0c-a9f7-52f4c09591be@apache.org> <CAK2_iMOpWe6Zr-9xbLz6T9ctkxfEOkm+=-kZUNRLHW_WXLQL7g@mail.gmail.com>
 <CA+0=VoVigmbiYe3fcS6_zwpcZWvku-rv_kxZ=yGFcbf8Fk44+w@mail.gmail.com>
 <CAGt6o8=DM1u78UWvRjp+MLf3_ra4vaNi43hT8-rTpmQ+vtiqtA@mail.gmail.com>
 <CAGcMBHhTfFZCUhO7uXbnaPKwNF=SKuh-CpwB7mVQnzXXzGYP4Q@mail.gmail.com> <CAGt6o8k=GiH8k2=2kAHTkArc8QY+vMf3-Wvd-ttd8m1R+PxQbg@mail.gmail.com>
From: Alexey Goncharuk <alexey.goncharuk@gmail.com>
Date: Wed, 2 Aug 2017 10:59:06 +0300
Message-ID: <CABDss3ht9jVmyROr1D19dvsACkZdpWAsFqcYC421gbAJ3z7pgA@mail.gmail.com>
Subject: Re: Thin client protocol message format
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="f403045c2b0863f41e0555c0a3e5"
archived-at: Wed, 02 Aug 2017 07:59:17 -0000

--f403045c2b0863f41e0555c0a3e5
Content-Type: text/plain; charset="UTF-8"

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
> >
>

--f403045c2b0863f41e0555c0a3e5--