thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Geyer <jensge...@hotmail.com>
Subject Re: Python client vs C# client json/binary different.. a lot of extra comma!! (confused)
Date Tue, 12 Mar 2019 21:46:38 GMT
> 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: user@thrift.apache.org
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 <jensgeyer@hotmail.com> 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?
>
>
>
>
>
>
>
>
>
>
>
> 

Mime
View raw message