0

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.

ArhiChief
  • 240
  • 2
  • 13
  • That sounds strange. Have you double checked the protocol/transport setup? Maybe you used (or did not use) framed transport in an unbalanced manner? Other than that I'm afraid that cries for having a reproducible test case. If you have one (the above is not, as it is missing some things), please share that information with us. Either here on SO or in the mailing lists. If you are sure it must be a bug, file a JIRA ticket. – JensG Oct 21 '14 at 19:12
  • I'm sorry, but I can't provide any test information, because my application recive information from service that inaccessible for me, but developers of that service assures that all my code is correct, and after translating it to Java everything works fine without cycles. Maybe the problem in thrift IDL to C# codegenerator? – ArhiChief Oct 22 '14 at 06:44
  • "*Maybe the problem in thrift IDL to C# codegenerator*" - No. Most likely not. But we get stuck here unless you are able to provide an [sscce](http://sscce.org) somehow. What about capturing the incoming data stream into a file? This way we will be able to feed it to the code at will. – JensG Oct 22 '14 at 08:12
  • Ok. I wrote incoming data into file. Here is the link to project https://github.com/ArhiChief/sudis_auth_lib. In the root dirrectory you will find _incomming_transmission.dat_ file and IDL (*.thrift) files what creates code of my classes. _sudis_auth_lib_ is the dirrectory, what contains code with "strange behavoiur" – ArhiChief Oct 22 '14 at 09:34

1 Answers1

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.

analysis

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.

JensG
  • 13,148
  • 4
  • 45
  • 55
  • Thank you. I think you are right and the problem in my decrypt routine. Before sending serialized data, service sign and encrypt it. Maybe I forgot to remove sign from decrypted data. But! In the code that I gave, there is anothe function that works same, but recivec another data, and everithing works fine. Otherwise, I will show your answer to service developers. Thanks again! – ArhiChief Oct 23 '14 at 05:49