Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
From: Andrey Kornev <andrewkornev@hotmail.com>
To: Pavel Tupitsyn <ptupitsyn@apache.org>, "dev@ignite.apache.org"
	<dev@ignite.apache.org>
Subject: Re: Thin Client Protocol documentation
Thread-Topic: Thin Client Protocol documentation
Thread-Index: AQHTY5JrNWf7hyO5MkGsF/eJfgcwTqMsrGcAgAAClQCAAarUgIAANTEAgAH9x2A=
Date: Sat, 2 Dec 2017 20:27:52 +0000
Message-ID: <MWHPR2201MB155129ED049EE2B0AE062326CF3E0@MWHPR2201MB1551.namprd22.prod.outlook.com>
References: <CAK2_iMOi3=RVszTTeS_=-VG1tpvwB7pozD1AGOSrtrqD+-kybg@mail.gmail.com>
 <5a1fc8da.10372e0a.dfa50.4edb@mx.google.com>
 <CAK2_iMOWztTM3=rKoL0RZSGWUBc-ugogFw+weU_8A528_+LJbg@mail.gmail.com>
 <5a213111.94a7190a.ba8a3.75d9@mx.google.com>,<CAK2_iMMdyCp8o29y4HC7ZNTG0jo6s203tcM1GQOg2nHEZsYipA@mail.gmail.com>
In-Reply-To: <CAK2_iMMdyCp8o29y4HC7ZNTG0jo6s203tcM1GQOg2nHEZsYipA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [9Q6pnE3nRasJ0eJK0U8GWMLJmj4lVpjf]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BL2NAM02HT089;6:HBqIRxMJ7MtbszUg9baMZfy0mbr6k6E1YYaC5zZzDn4S9psxxVdAViitfbZjYDp6yY3qPu9dZd8zHukfqZGtPiJtEK8hl2RciCRW5G//MWBN6IvdBF74ddkbjhzIfRKEwennesHk7xy4gPKYGttBki9r6LGnlM48cC353DiC9P8uxjfgQs6QfUF9BgthczunP64LQ8woYonrz/PEl/0hx40zQHagadlt2Mazg2jW03Pvr9R6z2OR11ccbelMj0dIJEez2Ivc3q6Yhhbf+++pvMZdEG8tmWGWP1u6RZM1v4HKlMJ8iKa6dndBsihPtm/ED3b4ExnASyNZMQam0tLkZWCJVD0s6GH1gqpcwCHTyAo=;5:iwj2OnQAfPh2qRppnDTh0MtGKpAeH83hoQNTT6Eb6XH7f0CJFVJrhSvFdAI4U/OjTxKJmf6hFFRQLMEtG9kchzOxZTsZtn+HrQovd4vEUyrRyE+TjWmZH+godzkA5dFjNBCSaMTp0plv2x/bhIqQ9ZqpCISMkZolGkGSydlpg6U=;24:jHILROE2XHIfm8VCdSKC8snEvOMW8ZxAxc9xFoo3nDtArjm4nLYMKRQkH+PpS7On9BfT67xnpGOCuuuVBsW3MA+mEwdYy4IShUf5DOd/eQo=;7:A6NPbyIE8hT8v/JglzDq+rl5NyHtC+xDejcGqpgr3gZWX805rWeiIAXS2im2jmDvBkcR0dw6dNcbf4QdQ+k1Q+nbvVPr5p8/K9Z55/yGOihs9ifvYIV3+xKLw0GrapDZ+0obRXo9GLSq2UfuIyz7cYMMfjb+m3xeRRh3dTUzWIX7lq8WsBOFaEFO2LvN3npVVKKNffleFw2Qy+zCM86RLWObeaBIrkgSnSAZJC6zusx8kvnpWeF4qk7Ot5ZXMEt7
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045);SRVR:BL2NAM02HT089;
x-ms-traffictypediagnostic: BL2NAM02HT089:
x-ms-office365-filtering-correlation-id: 8e671d2d-6a2e-4dde-0f86-08d539c329f0
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:BL2NAM02HT089;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:BL2NAM02HT089;
x-forefront-prvs: 0509245D29
x-forefront-antispam-report: SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:BL2NAM02HT089;H:MWHPR2201MB1551.namprd22.prod.outlook.com;FPR:;SPF:None;LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_MWHPR2201MB155129ED049EE2B0AE062326CF3E0MWHPR2201MB1551_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e671d2d-6a2e-4dde-0f86-08d539c329f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2017 20:27:52.6391
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT089
archived-at: Sat, 02 Dec 2017 20:28:06 -0000

--_000_MWHPR2201MB155129ED049EE2B0AE062326CF3E0MWHPR2201MB1551_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Pavel,

Great job on the Thin Client protocol design!

I'm a bit late to the party, but I'm wondering why none of the compute feat=
ures are supported? Such omission is unfortunate. Is it intentional? If so,=
 what are the reasons?

I think it would be useful for the clients to be able to invoke already dep=
loyed tasks/services, or send a closure (if the client happens to be writte=
n in Java) for execution.

Thanks
Andrey

________________________________
From: Pavel Tupitsyn <ptupitsyn@apache.org>
Sent: Friday, December 1, 2017 5:48 AM
To: dev@ignite.apache.org
Subject: Re: Thin Client Protocol documentation

There are no legacy formats. JDBC and ODBC clients are not "legacy", quite
the opposite.

In future we may even want to combine JDBC Thin and general-purpose Thin
clients since they have a lot in common.
So let's keep the handshake format consistent across clients.

> exceptions for message formats
Handshake is an exception anyway, it does not have (or need) requestId, etc=
.

On Fri, Dec 1, 2017 at 1:38 PM, Alexey Popov <tank2.alex@gmail.com> wrote:

> Pavel,
>
> I believe ClientListenerNioListener.onHandshake() could support more than
> one Handshake request format (be backward compatible), for instance, if w=
e
> will have a new handshake code =3D 0xABCD that differs from 0x01 byte.
>
> It is a design vs architecture question.
>
> I can=92t understand why the legacy Handshake format should be used for a
> new protocol. If this protocol is supposed to be public it should have no
> exceptions for message formats.
>
> Thank you,
> Alexey
>
> From: Pavel Tupitsyn
> Sent: Thursday, November 30, 2017 12:11 PM
> To: dev@ignite.apache.org
> Subject: Re: Thin Client Protocol documentation
>
> Hi Alexey,
>
> 1,2,3 are related only to handshake. All other operations are consistent.
>
> Handshake request format is dictated by existing client connector that is
> shared with ODBC and JDBC clients (see
> ClientListenerNioListener.onHandshake).
> so we can't add magic numbers or change operation code.
>
> But yes, we can add server version to the handshake response, and I think
> this makes sense.
>
> > 4. The same comments for success flag (1 byte) and status code (4 bytes=
)
> in responses. Let's leave only status code.
> We don't have a success flag in responses, there is just a 4-byte status
> code, 0 indicates success, everything else is an error.
>
> Thanks,
> Pavel
>
> On Thu, Nov 30, 2017 at 12:01 PM, Alexey Popov <tank2.alex@gmail.com>
> wrote:
>
> > Hi Pavel,
> >
> > Let me add my 5 cents.
> >
> > 1. It would be great if both Handshake request & response have some
> > "magic" number (2 or 4 bytes) inside their msg body. That will simplify
> > handling situations when non-Ignite client connects to Ignite server an=
d
> > vice versa.
> >
> > 2. It makes sense to add server version to successful Handshake respons=
e
> > as well. It will help to understand & debug possible backward
> compatibility
> > issues in the field by *.pcap logs analysis & etc.
> >
> > 3. Can we have a more strict header for all message types?
> > As far as I understand,
> > Handshake request has:
> > 1) length - 4 byte
> > 2) Handshake code - 1 byte
> > 3) body - (length - 1) bytes
> >
> > while OP_CACHE_GET request has:
> > 1) length - 4 byte
> > 2) OP_CACHE_GET code - 2 bytes
> > 3) request id - 4 bytes
> > 4) body - (length - 2 - 4) bytes
> >
> > Why some messages have Operation code with 1 byte while others - 2 byte=
s?
> > Why some requests/responses have request-id while others don't? Let's
> > simplify parser work )
> >
> > 4. The same comments for success flag (1 byte) and status code (4 bytes=
)
> > in responses. Let's leave only status code.
> >
> > Thank you,
> > Alexey
> >
> > From: Pavel Tupitsyn
> > Sent: Wednesday, November 22, 2017 4:04 PM
> > To: dev@ignite.apache.org
> > Subject: Thin Client Protocol documentation
> >
> > Igniters,
> >
> > I've put together a detailed description of our Thin Client protocol
> > in form of IEP on wiki:
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 9+Thin+Client+Protocol
> >
> >
> > To clarify:
> > - Protocol implementation is in master (see ClientMessageParser class)
> > - Protocol has not been released yet, so we are free to change anything
> > - Protocol is only used by .NET Thin Client for now, but is supposed to
> be
> > used from other languages by third party contributors
> > - More operations will be added in future, this is a first set of them,
> > cache-related
> >
> >
> > Please review the document and let me know your thoughts.
> > Is there anything missing or wrong?
> >
> > We should make sure that the foundation is solid and extensible.
> >
> >
> > Thanks,
> > Pavel
> >
> >
>
>

--_000_MWHPR2201MB155129ED049EE2B0AE062326CF3E0MWHPR2201MB1551_--