Hi,

Happy to see that you solved the problem. I'm very curious about what you
are doing, could you share some additional info? Can we help in any way?

Thanks

Luigi


2016-05-02 23:48 GMT+02:00 Ra Long <[email protected]>:

> Figured it out. I realized almost as soon as I submitted this that I was
> looking at the code for the master branch which is the release branch. The
> code for OrientDB v2.2.0-beta2 wouldn't be in that branch. So I went and
> looked at the OrientDB releases and looked at some of the commits to figure
> out which branch you guys were using and found the correct code which isn't
> reflected in the Binary Protocol documentation yet.
>
>
> https://github.com/orientechnologies/orientdb/blob/develop/server/src/main/java/com/orientechnologies/orient/server/network/protocol/binary/ONetworkProtocolBinary.java#L1923
>
> I see that additional fields were added:
> if (connection.getData().protocolVersion >
> OChannelBinaryProtocol.PROTOCOL_VERSION_33) {
>   connection.getData().supportsPushMessages = channel.readBoolean();
>   connection.getData().collectStats = channel.readBoolean();
> } else {
>   connection.getData().supportsPushMessages = true;
>   connection.getData().collectStats = true;
> }
>
> I've now added support for those fields prior to the username and password
> and everything is working.
>
> So then, the version 34+ REQUEST_CONNECT format is currently:
> (2)
> (driver-name:string)(driver-version:string)(protocol-version:short)(client-id:string)(serialization-impl:string)(token-session:boolean)
> *(supports-push-messages:boolean)(collect-stats:boolean)*
> (user-name:string)(user-password:string)
>
>
>
> On Monday, May 2, 2016 at 5:27:29 PM UTC-4, Ra Long wrote:
>>
>> I'm using the OrientDB v2.2.0-beta2 Docker. I'm experimenting with
>> building a binary protocol driver for a platform that doesn't currently
>> have a driver.
>>
>> The Binary Protocol documentation specifies that the format of the
>> REQUEST_CONNECT operation is:
>> (2)
>> (driver-name:string)(driver-version:string)(protocol-version:short)(client-id:string)(serialization-impl:string)(token-session:boolean)(user-name:string)(user-password:string)
>>
>> The RELEVANT OrientDB ONetworkProtocolBinary.java source code is:
>> From:
>> https://github.com/orientechnologies/orientdb/blob/master/server/src/main/java/com/orientechnologies/orient/server/network/protocol/binary/ONetworkProtocolBinary.java
>>
>> protected void connect() throws IOException {
>>         setDataCommandInfo("Connect");
>>
>>         readConnectionData();
>>
>>         connection.serverUser = server.serverLogin(channel.readString(),
>> channel.readString(), "connect");
>>         beginResponse();
>>         ...
>> }
>>
>> protected void readConnectionData() throws IOException {
>>         connection.data.driverName = channel.readString();
>>         connection.data.driverVersion = channel.readString();
>>         connection.data.protocolVersion = channel.readShort();
>>         connection.data.clientId = channel.readString();
>>         if (connection.data.protocolVersion > OChannelBinaryProtocol.
>> PROTOCOL_VERSION_21)
>>           connection.data.serializationImpl = channel.readString();
>>         else
>>           connection.data.serializationImpl =
>> ORecordSerializerSchemaAware2CSV.NAME;
>>         if (connection.tokenBased == null) {
>>           if (connection.data.protocolVersion > OChannelBinaryProtocol.
>> PROTOCOL_VERSION_26)
>>                 connection.tokenBased = channel.readBoolean();
>>           else
>>                 connection.tokenBased = false;
>>         } else {
>>           if (connection.data.protocolVersion > OChannelBinaryProtocol.
>> PROTOCOL_VERSION_26)
>>                 if (channel.readBoolean() != connection.tokenBased) {
>>                   // throw new OException("Not supported mixed
>> connection managment");
>>                 }
>>         }
>>         if (connection.tokenBased && tokenHandler == null) {
>>           // this is not the way
>>           // throw new OException("The server doesn't support the token
>> based authentication");
>>           connection.tokenBased = false;
>>         }
>> }
>>
>> Here's a hex string of the binary data I'm sending:
>>
>> 02FFFFFFFF0000000E41676170652E4F7269656E74444200000005302E302E31002200000000000000134F5265636F7264446F63756D656E74326373760000000004726F6F740000000870617373776F7264
>>
>> Here's the log text my code is generating for debugging purposes which
>> breaks the request up into the individual data pieces sent.
>> Format for numeric values is (type:value:hex)
>> Format for strings is (type:length:length_hex:value:value_hex)
>>
>> (byte:2:02)
>> (int:-1:FFFFFFFF)
>> (string:14:0000000E:Agape.OrientDB:41676170652E4F7269656E744442)
>> (string:5:00000005:0.0.1:302E302E31)
>> (short:34:0022)
>> (string:0:00000000::)
>>
>> (string:19:00000013:ORecordDocument2csv:4F5265636F7264446F63756D656E7432637376)
>> (byte:0:00)
>> (string:4:00000004:root:726F6F74)
>> (string:8:00000008:password:70617373776F7264)
>>
>>
>> Finally, here's the binary protocol debug log I'm getting from OrientDB:
>> 2016-05-02 19:41:02:124 INFO  /192.168.99.1:62676 - Connected
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:02:125 INFO  /192.168.99.1:62676 - Writing short (2
>> bytes): 34 [OChannelBinaryServer]
>> 2016-05-02 19:41:02:139 INFO  /192.168.99.1:62676 - Flush
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:02:216 INFO  /192.168.99.1:62676 - Reading byte (1
>> byte)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:182 INFO  /192.168.99.1:62676 - Read byte: 2
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:185 INFO  /192.168.99.1:62676 - Reading int (4
>> bytes)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:187 INFO  /192.168.99.1:62676 - Read int: -1
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:190 INFO  /192.168.99.1:62676 - Reading string (4+N
>> bytes)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:193 INFO  /192.168.99.1:62676 - Read string:
>> Agape.OrientDB [OChannelBinaryServer]
>> 2016-05-02 19:41:12:194 INFO  /192.168.99.1:62676 - Reading string (4+N
>> bytes)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:198 INFO  /192.168.99.1:62676 - Read string: 0.0.1
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:199 INFO  /192.168.99.1:62676 - Reading short (2
>> bytes)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:234 INFO  /192.168.99.1:62676 - Read short: 34
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:235 INFO  /192.168.99.1:62676 - Reading string (4+N
>> bytes)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:237 INFO  /192.168.99.1:62676 - Read string:
>>  [OChannelBinaryServer]
>> 2016-05-02 19:41:12:240 INFO  /192.168.99.1:62676 - Reading string (4+N
>> bytes)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:243 INFO  /192.168.99.1:62676 - Read string:
>> ORecordDocument2csv [OChannelBinaryServer]
>> 2016-05-02 19:41:12:244 INFO  /192.168.99.1:62676 - Reading boolean (1
>> byte)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:250 INFO  /192.168.99.1:62676 - Read boolean: false
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:251 INFO  /192.168.99.1:62676 - Reading boolean (1
>> byte)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:254 INFO  /192.168.99.1:62676 - Read boolean: false
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:264 INFO  /192.168.99.1:62676 - Reading boolean (1
>> byte)... [OChannelBinaryServer]
>> 2016-05-02 19:41:12:266 INFO  /192.168.99.1:62676 - Read boolean: false
>> [OChannelBinaryServer]
>> 2016-05-02 19:41:12:270 INFO  /192.168.99.1:62676 - Reading string (4+N
>> bytes)... [OChannelBinaryServer]
>>
>>
>> Where are the extra boolean reads coming from?
>> So for some reason, after the token-session value of false, OrientDB
>> seems to be trying to read additional boolean values but according to the
>> protocol documentation and the Java code, that doesn't make sense. The
>> OrientDB log looks like it's getting confused when reading the first bytes
>> of the username string length (00000004) as it does lead with zeros and
>> OrientDB does eventually try to read a string before my code kills the
>> connection due to a receive timeout. That makes no sense according to
>> the Java code though. It's calls to channel.readString() in connect() that
>> pull the username and password values so where are the extra boolean reads
>> coming from?
>>
>> I've also tried sending the client-id as a null string (-1) but get the
>> same results.
>>
>> Maybe I'm looking at the wrong Java code... I don't get it... Does anyone
>> see what I'm doing wrong here?
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to