Strange behaviour of Apache Thrift deserialization in .Net

Question

I use Apache Thrift in my applications to exchange data betwean several machines.

I recive data from outspace, create transport, protocol and deserialize recived data into object. Here is my code:

using (var memoryStream = new MemoryStream(data))
        {
            using (var transport = new TStreamTransport(memoryStream, memoryStream))
            {
                transport.Open();
                using (var protocolo = new TBinaryProtocol(transport))
                {
                    var result = new TCciUserLoginV1.cciUserLoginV1_result();

                    while (result.Success== null)
                    {
                        try
                        {
                            result.Read(protocolo);
                        }
                        catch { }
                    }

                    if (result.Success != null)
                    {
                        res = new RequestResult(result.Success);
                    }
                    else
                    {
                        res = new RequestResult(ResultCodes.LOCAL_ERROR");
                    }
                }
            }
        }

I know, that I recive binary serialized TCciUserLoginV1.cciUserLoginV1_result, because deserialization of other types throws an exception. But normal deserialization of result.Success property happens only after 10th iterration of while cycle. Whats why I used while. Can anybody tell me whats going on?

Thanks in advance.

Answer 1

It looks as if the incoming data buffer contains some garbage, see picture. Your data shown on top, a correct sample message using the same setup below.

The first byte of the data should be a type code byte followed by a 16-bit field ID, but in your sample both numbers are an completely insane: 48 is not a valid type code, and -32248 seems not like a proper field ID.

If one takes a closer look at the picture and compares with an correct sample using the same IDL definitions, it becomes clear that the message starts not at the beginning, rather somewhere in the middle at offset 0x59. So the data sent into Thrift for deserialization are not a valid data block, that's for sure.

Another indicator that something is seriously wrong could be the size difference between the two data samples: 2093 bytes vs. 93 bytes.

but developers of that service assures that all my code is correct, and after translating it to Java everything works fine without cycles.

That could be an indication that the problem lies in between what you receive and what comes out of the Decrypt() routine. Wild guess, but that would be the next thing to check. I'd compare what has been put into encryption on the other side and what comes out. Alternatively, compare the data BLOB with what the working Java test code sees after decrypting. There must be a difference somewhere.