Receiving data from QTcpSocket

Bonnie

@SPlatten
Wait, you are saying bytesWritten is never emitted in the sending side (the client)?
Then we should start from the sending part...

KroMignon

@SPlatten said in Receiving data from QTcpSocket:

The incomingConnection is getting called, in this slot I create a new client object using the descriptor parameter passed to the incomingConnection slot.
Data is sent from by the client application but I'm not seeing anything on the receiving application which is listening to localhost and port 8123.

Okay, let's continue step by step:

what is the return value of socket->write() from the client application? Do you really write something on TCP socket?
is bytesWritten(qint64) emitted on client side?
are you sure the event loop of the tread used by the socket is not locked? For example on server side waitForConnected() locks the event loop. The event loop have to be called to emit the bytesWritten(qint64) signal

Same on server side:

are you sure the event loop used by the connection socket in not locked

SPlatten

@KroMignon , I'm not calling socket->write(), I'm using QDataStream where I have an instance call mdsOut and sending data to that:

mdsOut << QJsonDocument(objMsg).toJson(QJsonDocument::Compact);

I'm not seeing anything written from the onBytesWritten slot. It does appear that the waitForConnection is blocking and never exits.

SPlatten

@Bonnie , I'm happy to try anything, apart from the initial connection, no data seems to be getting sent.

KroMignon

@SPlatten said in Receiving data from QTcpSocket:

I'm not calling socket->write(), I'm using QDataStream where I have an instance call mdsOut and sending data to that:

I would suggest you to change this to:

QByteArray block;
QDataStream  mdsOut(&block, QIODevice::WriteOnly);
mdsOut.setVersion(QDataStream::Qt_5_14);
//Build the module start-up message
QJsonObject objMsg;
objMsg.insert(clsJSON::mscszModule, clsModHelper::msszTitle);
objMsg.insert(clsJSON::mscszMsgType, clsJSON::mscszCmdInitial);
objMsg.insert(clsJSON::mscszPort, clsModHelper::muint16ModulePort);
mdsOut << QJsonDocument(objMsg).toJson(QJsonDocument::Compact);

write(block);

SPlatten

@KroMignon said in Receiving data from QTcpSocket:

QByteArray block;

Whats wrong with the way I did it? Thats what all the examples I've seen are doing?

KroMignon

@SPlatten said in Receiving data from QTcpSocket:

Whats wrong with the way I did it? Thats what all the examples I've seen are doing?

I don't know if there is something wrong, but this way you can check what and when something is written on TCP socket.
Which is what we want to achieve ==> be sure TCP client is sending something to server.

SPlatten

@KroMignon , right now it appears that the application is never getting past waitForConnected, even with a 20 second timeout.

KroMignon

@SPlatten said in Receiving data from QTcpSocket:

right now it appears that the application is never getting past waitForConnected, even with a 20 second timeout.

Please don't be hurt, but I am not a friend of doing synchronous/blocking calls with Qt. Qt base design is asynchronous.
I prefer using signals/slots mechanism and I am using connected(), disconnected() , bytesWritten(qint64) and readyRead() signals.

My application needs to run on Android, Linux and Windows and waitForConnected has issues with Windows, from documentation:

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

SPlatten

@KroMignon , I'm happy to change, the problem is there are so many incomplete and what seem poor examples online.

Could the problem be because I am using both synchronous and asynchronous methods in my application?

In the class constructor:

    connect(this, SIGNAL(connected()), this, SLOT(onConnected()));
    connect(this, SIGNAL(disconnected()), this, SLOT(onDisconnected()));
    connect(this, SIGNAL(readyRead()), this, SLOT(onDataIn()));
    connect(this, SIGNAL(bytesWritten(qint64)), this, SLOT(onBytesWritten(qint64)));

And then in the onConnect slot:

    qdbg() << clsModHelper::mscpszHost << muint16XMLMPAMport;
    connectToHost(clsModHelper::mscpszHost, muint16XMLMPAMport);
        
    if ( waitForConnected(clsModHelper::mscintConnectionTimeout) != true ) {
        emit terminateModule();
    }

Christian Ehrlicher

@SPlatten said in Receiving data from QTcpSocket:

the problem is there are so many incomplete and what seem poor examples online.

https://doc.qt.io/qt-5/qtcpsocket.html#details - not enough examples there? And if not - write a good example, provide a patch for Qt and we will happily review it...

SPlatten

@Christian-Ehrlicher , when I have a working example I might just do that.

Christian Ehrlicher

The Fortune Server/Client example is doing exactly what you try.

SPlatten

@Christian-Ehrlicher How do I download the Fortune Server and Client examples?

jsulm

@SPlatten said in Receiving data from QTcpSocket:

How do I download the Fortune Server and Client examples?

Examples are part of a Qt installation (if using Qt installer).

JonB

@SPlatten said in Receiving data from QTcpSocket:

Fortune Server and Client examples

You can also just visit the doc pages, the links are at the end of the pages: https://doc.qt.io/qt-5/qtnetwork-fortuneclient-example.html & https://doc.qt.io/qt-5/qtnetwork-fortuneserver-example.html

KroMignon

@SPlatten said in Receiving data from QTcpSocket:

And then in the onConnect slot:

qdbg() << clsModHelper::mscpszHost << muint16XMLMPAMport;
connectToHost(clsModHelper::mscpszHost, muint16XMLMPAMport);
    
if ( waitForConnected(clsModHelper::mscintConnectionTimeout) != true ) {
    emit terminateModule();
}

That is your problem!
You are "bad mixing" synchronous and asynchronous!

OnConnected() will be called when TCP server has accepted to the connection.
So you can start writing to server in this slot.
No need to use waitForConnected()

==> you only have to use connectToHost() to start connection request to TCP server.

JonB

@SPlatten said in Receiving data from QTcpSocket:

Could the problem be because I am using both synchronous and asynchronous methods in my application?

As @KroMignon says. Also I believe we have seen programs going wrong if they try to use the asynchronous signals at the same time as the synchronous waitFor..s, they get in each other's way IIRC.