Essentially 1 line change and it all works! #transport = TTransport.TBufferedTransport(TSocket.TSocket(host, port)) transport = TFramedTransport(TSocket.TSocket(host, port))
Hopefully this may aid others in the future somehow. Thanks for your patience and help! On Wed, Mar 13, 2019 at 5:46 AM Jens Geyer <[email protected]> wrote: > > > In the C# version the start is different? > > \x00\x00\x00\x82 > > vs > > \x80\x01\x00\x01 > > Right, and now that I look at it, I guess I know what the issue might be > > > \x00\x00\x00\x82 > > This is not a message header. It is the 4-byte length indicator of the > TFramedProtocol. The remainder of the message is 0x82 = 130 bytes. > > Could it be that the setup of the Thrift protocol/transport stack differs > between the two clients? What happens if you add TFramedProtocol to the > Python version? > > > I'm just not quite sure about this part that follows immediately: > > > \x0f\xff\x00\x01\x00\x00\x00\x01\x00\x01\x00\x00\x00\x00 > > From looking at the naked bytes, I have no idea what that could be. But that > may again become clearer, if you check the Thrift protocol/transport stack > setup used. > > > After that, the usual header etc follows: > > > \x80\x01\x00\x01 > message header > > \x00\x00\x00\x04auth > string length and message name > > etc. > > > > > -----Ursprüngliche Nachricht----- > From: C Bergström > Sent: Tuesday, March 12, 2019 2:54 AM > To: [email protected] > Subject: Re: Python client vs C# client json/binary different.. a lot of > extra comma!! (confused) > > I'll double check the bytes question below. I will probably need to spend 1 > day writing a parser for this though. > > In the C# version the start is different? > \x00\x00\x00\x82 > vs > \x80\x01\x00\x01 > > Is this just a different version of Thrift header? The binary looked so > different, but it should have been a similar length. I'll try to parse it > and see what I can understand. > > > On Tue, Mar 12, 2019 at 9:35 AM Jens Geyer <[email protected]> wrote: > > > Ok, I decoded the first part for you: > > > > Thanks! > > > > > > Python New > > > \x80\x01\x00\x01 > > Thrift message header > > > > > \x00\x00\x00\x04 > > string length = 4 > > > > > auth > > the string data = message name > > > > > \x00\x00\x00\x00 > > msg sequence nr > > > > > \x08 > > field type = 8 = i32 > > > > > \x00\x01 > > field ID = 1 > > > > > \x00\x00\x9cB > > i32 value = 0x9c00+66 = 40002 > > > > > \n > > field type = 10 = i64 > > > > > \x00\x02 > > field ID = 2 > > > > > \x00\x00\x00\x00\x03\x89\x05\x8a > > i64 value = 0x0389058a = 59311498 > > > > > \x0b > > field type = 11 = string > > > > > \x00\x03 > > field ID = 3 > > > > > \x00\x00\x00 > > string len ... should be 4 bytes ... is there one byte missing? or did you > > only lose it somewhere between debugger and email? > > > > > ED237CF629A6CD7AF601659A39CECFDC > > string data = 16 bytes > > > > > \x0b > > field type = 11 = string > > > > > \x00\x04 > > field ID = 4 > > > > > \x00\x00\x00\x1a > > string len = 0x1a = 26 > > > > > c#/unity,1.0 > > > beta,20141223 > > string data, as shown (incuding the line break) > > > > > \r > > > field type = 13 = map<> > > > > > \x00\x05 > > > field id = 5 > > > > > \x0b > > map key field type = 11 = string > > > > > \x0b > > map value field type = 11 = string > > > > > \x00\x00\x00\x00 > > number of entries in the map = 0 > > > > > \x00 > > field type = T_STOP > > > > So the only thing that looks strange is the length indicator right before > > "ED237CF629A6CD7AF601659A39CECFDC". But I can't really imagine that python > > only writes 3 of 4 bytes, that should have been found and fixed long ago > > if > > such a bug ever existed. > > > > Could you double-check that please? > > > > > > > > > > > > > > > > > > > > > > > > >
