not receiving on QAbstractSocket

mzimmers

Hi all -

I use a QAbstractSocket for a file transfer to an embedded target. The protocol is simple: I send a block of data, wait for an ack, then re-send, etc. until the file is fully transferred.

I'm not getting the acks back from the target. I see them in Wireshark (running on the same system as my Qt app). I even temporarily replaced the QAbstractSocket with Winsock 2, and my app gets the ack that way.

I honestly don't know what code I can post to be helpful, but here's some of it:

m_socket = new QTcpSocket;
...
m_socket->connectToHost(m_hostAddr, OTA_PORT_NBR, QIODevice::ReadWrite);
...   
bytesReadFromTarget = m_socket->read(buff, OTA_BUFFSIZE);

bytesReadFromTarget always comes back 0. I've also set a slot for the error() signal, and it isn't triggered on this read. The read simply isn't seeing the ack.

My writes work just fine.

I've looked through the page on QAbstractSockets, but I don't see any configuration options that look hopeful. Can someone give me an idea of what I'm doing wrong?

Thanks...

SGaist

Hi,

What about QDataStream's read transaction mechanism ?

When are you calling m_socket->read ?

mzimmers

Hi SGaist - I'll look into QDataStream.

Not sure what you mean by "when," but I'm reading immediately after a write. But it behaves identically if I insert a delay, and/or step through the code with the debugger, so I don't think that matters.

EDIT: not sure I'm doing it right, but here's my attempt with QDataStream:

QDataStream in(m_socket);
QString qs;
in.startTransaction();
in >> qs;

if (in.commitTransaction())
{
	cout << "in.commitTransaction() returned true." << endl;
}
else
{
	cout << "in.commitTransaction() returned false." << endl;
}

commitTransaction() returns false, indicating an error. It's not clear to me how I get additional information about the error.

jsulm

@mzimmers You should not read immediately or use a timeout. Use http://doc.qt.io/qt-5/qiodevice.html#readyRead signal and read in the slot you connect to it.

JonB

@mzimmers
I assumed your
bytesReadFromTarget = m_socket->read(buff, OTA_BUFFSIZE);
was indeed in your readyRead slot. Like @jsulm says, you must write your code so that it drops into the event loop and allow signals to arrive to call slots where you then do the reading.

J.Hilk

@mzimmers
to add to the previous posters.

You have the choice between 2 ways to do this. Synchronus and Asynchronus.

The recommended way is using the eventloop and reacting to the SIGNALS the QAbstractSocket emits.

If you insist on using the Snychronus way or you happend to not have a main evetloop, than you can use the calls waitForBytesWritten , waitForReadyRead etc.
But a quote for those function from the docu:

Note: This function may fail randomly on Windows. Consider using the event loop and the bytesWritten() signal if your software will run on Windows.

We all recommend the Signal/Slot communication, and that for good reasons ;-)

JonB

@J.Hilk
Absolutely! And since the OP said he has used Winsock 2, he must be Windoze. I think he should avoid the waitFor... approach, and stick to signals/sockets, as (IIRC) we have had other posts from Win users saying they have indeed had problems with the "wait" ones.

mzimmers

Thanks, everyone. I'm still trying to get the event loop model through my thick skull.

Here's the (successful) change:

void Ota::transfer()
{
...
            QObject::connect(m_socket, &QTcpSocket::readyRead, this, &Ota::readAck);
            sendPacket(); // initial send; further sends will come from signals.
...
void Ota::readAck()
{
    // read an ack from the ESP32.
    qint64 bytesReadFromTarget;
    char buff[OTA_BUFFSIZE];

    bytesReadFromTarget = m_socket->read(buff, OTA_BUFFSIZE);
    if (!strncmp(buff, ACK, strlen(ACK)))
    {
        // successful ACK receipt; send another section of the file.
        sendPacket();
    }
    else
    {
        cerr << "Didn't get ack for TCP socket write; errno is " << errno << endl << flush;
    }
}

Works much better now. It's still a bit of a mystery why I need these acks in the first place, though...I thought TCP should handle that for me, but without them, I overrun the buffer on the target. Anyway...

Thanks again for all the help.