ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Thin client / Binary protocol: questions
Date Wed, 28 Feb 2018 13:52:40 GMT
> This is not part of protocol specification. Please refer to .NET client
> where it is already implemented. *Pavel*, do we have docs for this?

I don't think we have docs for SLL.
These docs should be common for any type of client (ODBC/JDBC/...),
and this is mostly about configuring certificates on server.

Otherwise it is just standard SSL/TLS, not much to document.
For .NET I've used standard SslStream, most languages/frameworks have this
in one form or another.


> node failover algorithm
See the following:
* https://issues.apache.org/jira/browse/IGNITE-7282
*
http://apache-ignite-developers.2346864.n4.nabble.com/Thin-client-failover-mechanism-ODBC-JDBC-td26553.html


Thanks,
Pavel


On Wed, Feb 28, 2018 at 1:32 PM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Hi Alex,
>
> >>> Just to double-check - we should support the types from the spec only.
> Right?
> Please provide the list of types you are in doubt of
>
> >>> - Key-Value and SQL and Scan Queries.
> >>>  The most of operations has "Flag" field in Request: "Pass 0 for
> default, or 1 to keep the value in binary form."
> >>>  What is it for?
> Please see IgniteCache.withKeepBinary method. For SQL this flag has no
> effect. For complex SCAN queries with filters this defines whether with
> pass real objects or binary objects to the filter.
>
> >>>  Java and .net libs always pass 0. Why?
> There is no Java client at the moment. As far as .NET, it doesn't support
> binary mode at the moment.
>
> >>>  Why an app working remotely via the binary protocol should know the
> exact platform where the node is running?
> Because if node is started from .NET, you may execute both Java filters and
> .NET fitlers on it. This flag defines what kind of filter is passed.
>
> >>> - Binary Type operations (register/get type name, put/get type).
> >>>  What are they for?
> >>>  What is a use case?
> Please get familiar with binary type concepts, especially binary metadata:
> https://apacheignite.readme.io/docs#binaryobject-type-metadata
>
> >>>  - Just interesting - why it was decided that hash code should be also
> calculated on a client side? Why it could not be returned by a server side?
> Because this is inefficient - we would have to rebuild binary objects on
> the server side. Instead, it is better to implement pretty simple routine
> for hashcode calculation inside every client.
>
> >>> - Name/password authentication.
> >>> When will it be available in the spec?
> >>> Is there any draft we can look at?
> It is still under development. Will be available in several weeks. It is
> better to skip this part for now.
>
> >>> - SSL/TLS communication.
> >>> When will it be available in the spec?
> This is not part of protocol specification. Please refer to .NET client
> where it is already implemented. *Pavel*, do we have docs for this?
>
> >>> - As Denis said, we should implement a node failover algorithm
> (switching to another predefined node).
> >>> Should the algorithm be the same in all thin libs?
> >>> Is it described somewhere?
> >>> We have not found it in java and .net libs. Will it be supported by
> them? When?
> It is still under development, will be ready in 1-2 weeks. Please skip for
> now. Yes, it is better to have the same algorithm on all clients for the
> sake of consistency.
>
> >>> - We are going to write the lib readme/guide in the markdown format and
> place it at the repo (.md file).
> >>> Is it OK? Or should we use dash.readme.io ?
> All our documentation is hosted on readme.io. There should be no
> exclusions. *Denis*, could you make sure that necessary spaces and
> permissions are set up?
>
> >>>  - May we easily use 3rd-party components with the following licenses?
> As a general rule of thumb it is not recommended to use any external
> libraries. The whole Ignite core is built with almost no dependencies, not
> to say about much less complex thin clients ans JDBC/ODBC drivers. IMO the
> only possible place where external dependency might be required is SSL
> support (e.g. we use OpenSSL for ODBC).
>
> Vladimir.
>
> On Wed, Feb 28, 2018 at 9:41 AM, Alexey Kosenchuk <
> alexey.kosenchuk@nobitlost.com> wrote:
>
> > Folks,
> >
> > Designing node.js thin lib (IGNITE-7777) we have the following questions.
> > Could you please have a look and clarify.
> >
> > Thanks,
> > -Alexey
> >
> > - Supported standard types and their type codes.
> >   Are defined in the spec: https://apacheignite.readme.io
> > /docs/binary-client-protocol#data-format
> >   But, as we see, java and .net libs (common parts which are used by thin
> > clients as well) support additional types and type codes, not described
> in
> > the spec. Eg. defined here: https://github.com/apache/igni
> > te/blob/master/modules/core/src/main/java/org/apache/ignite/
> > internal/binary/GridBinaryMarshaller.java
> >   Just to double-check - we should support the types from the spec only.
> > Right?
> >
> > - Key-Value and SQL and Scan Queries.
> >   The most of operations has "Flag" field in Request: "Pass 0 for
> default,
> > or 1 to keep the value in binary form."
> >   What is it for?
> >   Java and .net libs always pass 0. Why?
> >
> > - OP_QUERY_SCAN: Filter platform.
> >   Why is it required?
> >   Why an app working remotely via the binary protocol should know the
> > exact platform where the node is running?
> >
> > - Binary Type operations (register/get type name, put/get type).
> >   What are they for?
> >   What is a use case?
> >   It seems possible to put data of any binary object type into a cache
> w/o
> > registering type name and structure in advance.
> >
> > - OP_REGISTER_BINARY_TYPE_NAME, OP_GET_BINARY_TYPE_NAME: Platform id.
> >   Is it a type of the node platform?
> >   Why a remote app should know it?
> >   Why non-identical values are used here and in OP_QUERY_SCAN: Filter
> > platform?
> >
> > - OP_REGISTER_BINARY_TYPE_NAME, OP_PUT_BINARY_TYPE
> >   Why the both - Type name and Java-style hash code of the type name -
> are
> > in the request? (The same for Field name and Java-style hash code of the
> > field name.)
> >   Seems redundant.
> >
> > - Just interesting - why it was decided that hash code should be also
> > calculated on a client side? Why it could not be returned by a server
> side?
> >   Eg. OP_CACHE_CREATE_WITH_NAME Response can return hash code for the
> > provided Cache name.
> >   That would simplify thin client implementations, guarantee
> > consistency/correctness of hash code calculations...
> >
> > - Name/password authentication.
> >   When will it be available in the spec?
> >   Is there any draft we can look at?
> >
> > - SSL/TLS communication.
> >   When will it be available in the spec?
> >   Is there any draft we can look at?
> >
> > - As Denis said, we should implement a node failover algorithm (switching
> > to another predefined node).
> >   Should the algorithm be the same in all thin libs?
> >   Is it described somewhere?
> >   We have not found it in java and .net libs. Will it be supported by
> > them? When?
> >
> > - Is there any recommendation/suggestion how to test a node failover case
> > on a thin client side?
> >
> > - We are going to use jsdoc comments for the API methods:
> > http://usejsdoc.org/
> >   This tool, for example, may be used to generate the API spec from the
> > comments: https://www.npmjs.com/package/jsdoc
> >   Any objections?
> >
> > - We are going to write the lib readme/guide in the markdown format and
> > place it at the repo (.md file).
> >   Is it OK? Or should we use dash.readme.io ?
> >
> > - May we easily use 3rd-party components with the following licenses?
> >     -- Apache 2.0
> >     -- MIT
> >     -- GNU LGPL v3
> >     -- GNU GPL v2
> >   Should we pre-approve somehow / notify somebody about usage of concrete
> > 3rd-party components?
> >
>

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