Problems with TCP Raw Data

[wysota]

Because of this statement: The QDataStream class provides serialization of binary data to a QIODevice.

Was the data serialized on the other end with QDataStream as well?

[milot]

Yes,

Because the devices wait for response from the server, so I sent the response.

First I am able to get the IMEI number from the device using this code:

quint16 hd;
 
 
  QDataStream in(tcpClient);
  in >> hd;
 
  qDebug() << "Header: " << hd;
 
  char *data = new char[hd];
  in.readRawData(data, hd);
 
  QString str = QString::fromUtf8(data);
 
  qDebug() << "IMEI: " << str;

quint16 hd;


  QDataStream in(tcpClient);
  in >> hd;

  qDebug() << "Header: " << hd;

  char *data = new char[hd];
  in.readRawData(data, hd);

  QString str = QString::fromUtf8(data);

  qDebug() << "IMEI: " << str;

To copy to clipboard, switch view to plain text mode 

The device first sends its IMEI number and waits for response codes 00 (that is deny and it stops sending packets) and 01 (server tells the device to proceed with other info). I send this packet to the device using the following:

QByteArray ba;
  QDataStream out(&ba, QIODevice::WriteOnly);
  out << true;
 
  tcpClient->write(ba);

QByteArray ba;
  QDataStream out(&ba, QIODevice::WriteOnly);
  out << true;

  tcpClient->write(ba);

To copy to clipboard, switch view to plain text mode 

Then the first output is like this:

New connection from:  "91.187.105.189" 
Header:  15 
IMEI:  "352848021535568"

New connection from:  "91.187.105.189" 
Header:  15 
IMEI:  "352848021535568"

To copy to clipboard, switch view to plain text mode 

after the server sends the 01 (boolean value in my case) to the device, I get this:

Header:  0 
IMEI:  "x!��"

Header:  0 
IMEI:  "x!��"

To copy to clipboard, switch view to plain text mode 

Which seems to be very strange!

[wysota]

How does the transmission look like on the transmitting end? Mixing serialized and raw data in QDataStream is a bad idea in general, by the way. Also why doesn't the data stream work directly on the socket but instead it operates on some byte array that is then transmitted through the socket? I fail to see the point of using QDataStream in such a situation.

[milot]

I am not able to see the other end because it is a GPS device that transmits and receives data.

So are you suggesting that I should read the packets using only readRawData()?

I cannot find enough documentation on how to treat such situations, if you have something worth sharing I would be more than happy

[wysota]

I am not able to see the other end because it is a GPS device that transmits and receives data.

And it uses QDataStream??????????????????????????? I never heard of a GPS device using QDataStream as its communication protocol... Are you sure of that? Or have I misunderstood your "yes" answer to my question about whether the data was serialized using QDataStream?

[milot]

It uses TCP as communication protocol, for that reason I am trying to read from QTcpSocket using QDataStream!

As far as you can see on my example above, it receives data as expected and sends the data back to the device, because if I don't send data back to the device I am not able to receive any more data. For sending and receiving I data I'm using QDataStream, I pasted code above that I am able to read the header using QDataStream and write to the device using writeRawBytes() function.

[wysota]

QDataStream is not a general purpose stream for reading and writing non-textual data. It is a serialization mechanism with its own protocol. You can't use it to read data from an arbitrary binary stream. Using only readRawBytes() and writeRawBytes() with QDataStream only adds overhead without giving anything in return. If you know how many bytes to read then just read them and interpret them the way the other end of the communication expects you to.

[milot]

Thank you for the clarification.

Now I am avoiding using QDataStream, because in general serialization purposes I use QDataStream very often, and after reading that it has support for readRawData I thought it was the way to go.

Thank you again, whenever I come with a solution I will inform the others in this post as well.

[wysota]

Your problem is probably that you are going out of sync somewhere with your data. You have to remember you can't just read all data that is available in the socket and expect it to contain exactly as many bytes as you would want. Data needs to be buffered and reading needs to be deferred to a time when you are sure the buffer contains all the data you need.