CODEWITHSUNDEEP
c++qtsocketsnetwork-programmingtcp
panc_fab
panc_fab

Reputation: 530

QTcpSocket sends more data than wanted - Qt/C++

first of all a little background on my situation: - Qt/C++ UI desktop application - embedded device (Stm32l4xx family) +ATWINC1500 wifi module

I'm developing the gui application in order to send commands and files to the emdedded device via sockets.

For simple commands I've done all successfully, but for sending files (text files in GCODE format) I am stuck with some issues. The embedded device has already a socket management(not written by me, so I have not the possibility to modify the way sockets are managed, coming from third party company), and the reception of that type of files is managed in a way that the API waits for every single line of the file being sent, and then wrotes it into a reserved portion of the flash.

My problem is that when I send file from qt Application(by reading each line and and calling write() on the line, in reality my socket sends an entire chunk of the file, like 50 lines, resulting in my device not managing the file reception.

My sending code is this:

void sendGCODE(const QString fileName)
{
    QFile *file = new QFile(fileName,this);
    bool result = true;
    if (file->open(QIODevice::ReadOnly))
    {

      while (!file->atEnd())
      {
          QByteArray bytes(file->readLine());

          result = communicationSocket->write(bytes);
          communicationSocket->flush();
          if(result)
          {

              console->append("-> GCODE line sent:"+ QString(bytes));

          }
          else
          {
              console->append("-> Error sending GCODE line!");
          }
       }
       file->close();
    }

}

Have anyone of you guys any hints on what I am doing wrong? I've already searched and someone suggests on other topic that for this purpose it should be better to use UDP instead of TCP sockets, but unfortunately I cannot touch the embedded-device-side code. thank you all!

EDIT

After suggestions from comments, I've sniffed tcp packets and the packets are sent correctly(i.e. each packet contains a single line). BUT... at the receiver(device), I understood that there is something regarding memory which is not well managed. an example:

I'm trying to figure out how I could reset that part of memory.

Upvotes: 0

Views: 176

Answers (1)

Kuba hasn't forgotten Monica
Kuba hasn't forgotten Monica

Reputation: 98505

This is all wrong. TCP is not a message-oriented protocol. There is no way to ensure that the TCP packets contain any particular amount of data. The receiver code on the device mustn't expect that either - you perhaps misunderstood the receiver's code, or are otherwise doing something wrong (or the vendor is). What the receiver must do is wait for a packet, add the packet's data to a buffer, then extract and process as many complete lines as it can, then move the remaining data to the beginning of the buffer. And repeat that on every packet.

Thus you're looking for the wrong problem at the wrong place, unless your device never ever had a chance of working. If that device works OK with other software, then your "packetized" TCP assumption doesn't hold any water.

Here's how to proceed:

  1. If the device is commercially available and has been tested to work, then you're looking in the wrong place.

  2. If the device is a new product and still in development, then someone somewhere did something particularly stupid and you either need to fix that stupidity, or have the vendor fix it, or hire a consultant to fix it. But just to be completely clear: that's not how TCP works, and you cannot just accept that "it's how it is".

Upvotes: 0

Related Questions