@VRonin said in Need Help with getting a slot executed in the correct thread:

the default implementation of QThread::run starts an event loop so if you use the method described in that link everything will work out of the box

Indeed it does! Thanks!

@Allerknappe should your question better suited for AWS support team? or cloud forum? It seems not related to Qt itself.
Anyway, from little experience with a (non Qt) REST server running in AWS, in that case the server was configured with "internal" IP and then the AWS security team forwarded the proper port(s) so the solution could be available from outside.

@mrjj Cheers, that worked for me :)

Isn't this the same issue as here https://forum.qt.io/topic/75821/qabstractsocket-unknownsocketerror-provides-errorstring-of-unknownerror?

I had the same issue. The QIODevice::readAll() (which is called from QNetworkReply) function states this issue:

This function has no way of reporting errors; returning an empty QByteArray can mean either that no data was currently available for reading, or that an error occurred. This function also has no way of indicating that more data may have been available and couldn't be read.

The resolution is to connect QIODevice::readyRead to as per the documentation:

connect(reply, &QIODevice::readyRead, this, [=]() { QByteArray response = reply->readAll(); qDebug() << response; });

@kshegunov thank you very much really appreciate you taking your time to explain all this to me. And your are right. as soon as i connected both disconnect signals to the deleteLater() and went down the signals and slots road all the problems vanished. Thank you really. Because i had alot of time to spare i also followed @herlarbee suggestion(even though i watched this videos already) then decided to write a seperate server using QThreadPool approach seen on in the video title "Qt TCP Server design revisited". Then i benchmarked both. This new server after doing some benchmark test using ab tool in apache seems to outperform my previous solutions and handles alot more connections faster. Right now am very happy. When asking this question i just had 200 client limit in my brain but i got solutions that go way beyond that. Thank you guys.

Cheers !!!

@mrjj said:

but does QSslSocket not inherited QTcpSocket ?

Yes, you're right thank you !

Hi,

There's also the Chat Example that may be of use.

Fixed the problem:

On Client-Side and on Server-Side i provide the following:

Private key of the certificate Public key of the certificate Public key of the CA

An connection is established. I am getting an SSLError: "The certificate is self-signed and untrusted", but i can either ignore it using ignoreSslErrors(); or the better method is by comparing the certificates to make sure it's all good.
Also i have re-created my certificates and my CA with the correct information, because I haven't provided the CN for localhost since i was testing on my local machine with my old certificates.

Anyways, the communication works with correct certificates.

@cemaldemir07 said:

I think the solution is using x64 for more stable but not exact solution.

No. If you have a bug in the 32 bit version, switching to 64 bits will not change that. You need to apply yourself, find the problem and ultimately fix it.

It is working now and the reason was the listen() was in the wrong position and you need an additional Signal/Slot connection from main program to the network extension as following:

the main program gets changed like this:

wifi= new WirelessNet(0); QThread *thread = new QThread; wifi->moveToThread(thread); connect(thread,SIGNAL(started()), wifi,SLOT(initWifi())); thread->start();

the constructor of WirelessNet is now empty, therefore it gets a new public slot function:

void WirelessNet::initWifi() { listen(QHostAddress::Any, 5220); }

And that's the trick.

If one is creating a WirelessNet-Instance, starts listenting inside the constructor but first then uses the movetoThread(), the connection is lost.

Concluding in one sentence: First move to the right thread and afterwards start listening

Thanks for your help. Let me tell you I hate the official Qt-""Tutorials""

It could be. Although it was working fine in previous release with Qt 5.5.1.

Nice you found out and thanks for sharing :)

There's no need to modify the title anymore to mark the thread as solved, you can use the "Topic Tool" button for that :)

I found the solution:
The socket is setup within a thread and it's waiting / blocked by QWaitCondition until a message is send. When a message is send, the thread wakes up, the socket sends the message and waits until readyRead or timeout is triggered. That's working, but after that the thread is going to wait again and the socket is blocked again, so this is why the disconnect signal didn't get through.

Now I replaced the QWaitCondition by waitForDisconnect() and so the socket is not blocked anymore by the wait condition, and the disconnect signal gets through.

I think this is solved.

Ok guy thank you for that much replies :P! I solved the issue by myself anyway. In case sombebody has a similar problem here comes the solution:

What I did wrong was that I connected a time consuming function to the UpdateClient::tcpReady() slot. In this function I did some stuff which also lead to the emission of UpdateClient::tcpReady(). This broke the QEventQueue. So to what I had to chance was to skip the direct signal slot connection an do this in the UpdateClient::tcpReady():

QTimer::singleShot(0, this, SIGNAL(updateAvailable()));

No everything is working fine ;).

Hi,

since I am convinced that somebody else will also have similar problems I wrote a tutorial how to create a multithreaded server:

https://five-s.de/en/how-to-create-a-multithreaded-server-in-qt

Best regards

@Pepek said:

if (m_uiBlockSize == 0) {
if (bytesAvailable < (int)(sizeof(quint64) + sizeof(unsigned char)))
return;

in >> m_uiBlockSize; in >> m_uiCurrentScanType; //m_timer->singleShot(2000, this, SLOT(resetTCPConnection));

}

It's because in unsigned char I have data type that is coming next. I take it into account every time, but truth be told, it is unnecessary to be in header.