tcp readed data has other bytes than expected

[eschgi]

Hello,

in our company we use your library in our python services to manage our tcp connections. Actually we have a very strange problem and we do not know exactly from which layer the problem is caused.

From our analytics the problem could be produced by our code or the pyuv library or the libuv library.

We receive following piece of data from the tcp socket:

{"LM":0,"FTT":0.515,"TU1":0.515,"TU2":\xd8\xee\x8c\x03"ENTNAHME":null,"WT":0,"ARTICLEID":172,"NET":0.524,"TO2":0.0,"TO1":0.545,"TARE":0.018,"QN":0.515}

This payload should be a json document, but the value of TU2 was replaced by this value: \xd8\xee\x8c\x03. This value was logged with repr(). The real value is 4 Bytes long.

What we have found out that every time when this error occurs 4 Bytes are replaced with a wrong value. The big problem is that we can't reproduce the error.

So my question is if it is possible to update the pyuv library to the latest libuv version.
So we could test the new version and check if the error still exists.

Our used os is WINDOWS!

Thank you and kind regards!

[saghul]

Hi!

I doubt the libuv version has anything to do with this problem. Where do those 4 bytes come from? What encoding is that string using? Any chance you can take a packet capture with Wireshark to analyze it?

Cheers!

[eschgi]

Hi!

Thanks for the quick response. We have already done a wireshark packet capture. What we have seen is that the packets are correct in the wireshark packet capture. When we then read the data from the socket, the data is wrong.

We don't know where this 4 bytes are come from =(! Encoding is UTF-8.

Cheers!

[saghul]

Ohai! Any chance you can share a packet capture? Also, can you reproduce the bug by simulating the payload?

[eschgi]

No, we can't reproduce the bug. I can share the packet capture, but i think it would not help much.