Two way comms via socket?

[SPlatten]

@KroMignon , no what's Naggle's algorithm ?

Wireshark must be ok, because the only address and port I'm sending JSON on is 8123

A sample from Wireshark:

19	2.131440	::1	::1	TCP	131	50625 → 8123 [PSH, ACK] Seq=59 Ack=1 Win=407744 Len=55 TSval=15333115 TSecr=15331092

This is from 50625 -> 8123, no idea what 50625 is? Then immediately after this entry in Wireshark is:

20	2.131460	::1	::1	TCP	76	8123 → 50625 [ACK] Seq=1 Ack=114 Win=407680 Len=0 TSval=15333115 TSecr=15333115

[KroMignon]

@SPlatten said in Two way comms via socket?:

no what's Naggle's algorithm ?

As written earlier (https://forum.qt.io/post/639857), this is the TCP algorithm which handles transmission rules to avoid sending too much small packets.

[JonB]

@SPlatten said in Two way comms via socket?:

what's Naggle's algorithm ?

It's Nagle's algorithm, as @KroMignon wrote :)

However, it is "unusual" to disable this on a socket, it defaults to on for a good reason. If @KroMignon says

You have to call QTcpSocket::flush() to force data sending to counterpart.

and that works I would use that rather then changing the socket option....

[KroMignon]

@JonB said in Two way comms via socket?:

However, it is "unusual" to disable this on a socket

It depends, there are always use cases for this: localhost or local network sockets

[SPlatten]

@JonB , I've added:

psckReceiver->flush();

After write and also added the call to:

mpsckReceiver = new QTcpSocket();
mpsckReceiver->setSocketOption(QAbstractSocket::LowDelayOption, 1);

Still the same, A is receiving but the Ack message is not appearing in WireShark.

[JonB]

@SPlatten
Then by all means try the socket option, as I said I don't know whether that has the same effect. Once neither flushing nor disabling Nagle works, whatever your issue it is something else.

[KroMignon]

@SPlatten said in Two way comms via socket?:

Still the same, A is receiving but the Ack message is not appearing in WireShark.

So there are not so many options in my eyes:

• you are sending on wrong socket
• the socket is closed (did you check return value of QTcpSocket::write() ?)
• the event loop is locked, QTcpSocket requires a working event queue to work.

[SPlatten]

@KroMignon , I modified the onSendJSON slot:

void clsModule::onSendAck(const QJsonObject& crobjJSON, QTcpSocket* psckReceiver) {
    QJsonObject::const_iterator citrFound = crobjJSON.find(clsJSON::mscszMsgType);

    if ( citrFound == crobjJSON.end() ) {
        return;
    }
    QString strAck(clsJSON::mscszAck + citrFound.value().toString());
    QJsonObject objAck;
    objAck.insert(clsJSON::mscszAddrTo, cstrGetAlias());
    objAck.insert(clsJSON::mscszMsgType, strAck);
    objAck.insert(clsJSON::mscszSource, clsJSON::mscszXMLMPAM);
qdbg() << "clsModule::onSendAck: " << QJsonDocument(objAck).toJson(QJsonDocument::Compact);
    if ( mblnReady != true ) {
        sendLater(cstrGetAlias(), objAck);
    } else if ( psckReceiver != nullptr ) {
        QAbstractSocket::SocketState eState(psckReceiver->state());

        if ( eState == QAbstractSocket::ConnectedState ) {
            QByteArray arybytMsg(QJsonDocument(objAck).toJson(QJsonDocument::Compact));
            qint64 int64Write = psckReceiver->write(arybytMsg);
qdbg() << "clsModule::onSendAck, int64Write: " << int64Write;
            psckReceiver->flush();
        }
    }
}

Now its working, annoyingly I'm not sure what I've changed that has fixed it...Thank you to @KroMignon and @JonB.