reinterpret_cast for received tcp packets
-
Casting a struct to a received bunch of bytes is not correct. It may work now but fail as soon as a small piece changes. Therefore you have to describe the bytes on the paket (e.g. in an interface document) and decode them accordingly. Everything else is a hack.
@Christian-Ehrlicher The interface is well documented and both sites agreed to it. So there will be no change to that without further discussion between me and our partner :)
-
@Christian-Ehrlicher The interface is well documented and both sites agreed to it. So there will be no change to that without further discussion between me and our partner :)
@Redman said in reinterpret_cast for received tcp packets:
The interface is well documented and both sites agreed to it. So there will be no change to that
-
@Christian-Ehrlicher The interface is well documented and both sites agreed to it. So there will be no change to that without further discussion between me and our partner :)
@Redman said in reinterpret_cast for received tcp packets:
The interface is well documented and both sites agreed to it.
Then you would not have asked any of the questions above nor any problems wrt connecting to another process.
-
@Redman said in reinterpret_cast for received tcp packets:
The interface is well documented and both sites agreed to it.
Then you would not have asked any of the questions above nor any problems wrt connecting to another process.
-
@Christian-Ehrlicher And you live in a perfect world where no problems occur? :)
@Redman said in reinterpret_cast for received tcp packets:
And you live in a perfect world where no problems occur?
No, but your questions/problem revealed a basic lack of a "well documented" interface.
-
Hello,
I am developing an app on a 64bit windows machine.
Im using Qt 6.8.1 and the c++20 standard.My app receives tcp packets from an app running on windows.
I try to reinterpret_cast the packets into following struct.struct Coordinate { quint32 id; quint16 mode; qint32 x; quint64 y; qint32 z; };like followed
void MyReceiver::recEchoDataReady() { QByteArray bytes = m_tcpServerClient->readAll(); Coordinate pt = *reinterpret_cast<Coordinate*>(bytes.data()); QMap<QString, QVariant> coord; coord.insert(QStringLiteral("ID"), pt.id); coord.insert(QStringLiteral("MODE"), pt.mode); coord.insert(QStringLiteral("X"), pt.x); coord.insert(QStringLiteral("Y"), pt.y); coord.insert(QStringLiteral("Z"), pt.z); emit echoDataReady(coord); }This approached worked flawlessly. We transmitted several millions of packets over the course of a couple of months without any problems. No need for checking if the tcpSocker buffer is empty or if the available bytes in the buffer are only partially tansmitted etc.etc. Simply readAll bytes and cast it to the desired struct.
Recently there were changes made on the sender site of this protocol. They switched from a c++ app to a python app.
Following you can see the hex representation of the bytes that arrived at my site. If you try to fit this into the struct you would think that the data within the struct would be 1 1 1 1 1.01:00:00:00:01:00:01:00:00:00:01:00:00:00:00:00:00:00:01:00:00:00Unfortunately after casting that ByteArray to my struct I get following values
1 1 65536 65536 -1870011232Now I'm not sure if there are any incompatibilities between c++ and python datatype.
I'm kinda stuck on this problem and have no clue why that is happening.If anyone has an idea on how to investigate this or provide a meaningfull explanation it would be greatly appreciated.
@Redman said in reinterpret_cast for received tcp packets:
01:00:00:00:01:00:01:00:00:00:01:00:00:00:00:00:00:00:01:00:00:00
This is what you'd expect for a packed struct (as you have figures out). It worked before because both sides were using C++ and so both sides were not using packed structs (so much about the "well defined protocol").
In order to not have that problem @J-Hilk is right to write a constructor expecting a QByteArray. For sending you should also pack the members into a QByteArray yourself. This also makes you immune to the order of the members (which is only guaranteed by a very, very recent C++ standard). It is also common practice to order members from biggest to smallest, so you can adhere to alignment rules and still get the most compact representation. This would also solve your problem (on the C++ side; I don't know Python) that you don't have to explicitly pack the struct.
