I ported the official OrientDB driver over to .NET Core RC2 which required some tweaking but I have it working. Ultimately though, I'm just not satisfied with it. My main issues with it are the limited documentation and deviation from the Java API. Granted, it's actually simple work with the driver but it's not the best for introducing a development team to graph databases in general and OrientDB specifically. The .NET driver has limited documentation and an API that deviates from the Java API which is what the majority of the examples they're likely to find on the web address. This hinders ramp up and productivity.
Beyond that, after becoming so familiar with the driver's source code through porting it, I have some currently untested concerns about the driver's scalability. Even at a surface glance, the driver's source code *appears* to have a bit more abstraction going on than necessary. This is then followed by a complete lack of any asynchronous programming APIs. The issue I was having that led me to post here in the first place, turned out to be a result of me targeting OrientDB v2.2.0-beta2 when the .NET driver doesn't support the latest binary protocol version. This is of no fault to OrientDB nor the writers of the .NET driver. On Tuesday, May 3, 2016 at 3:25:38 AM UTC-4, Luigi Dell'Aquila wrote: > > 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 <rlo...@gmail.com <javascript:>>: > >> 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 orient-databa...@googlegroups.com <javascript:>. >> 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
