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

@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 !!!

I agree with stack overflow. Your design is flawed. The state machine behind the communication should not depend in any way on the interface

Hi,

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

Hi and welcome to devnet,

Maybe QNetworkProxy might something.

Hope it helps

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.

Hi and welcome to devnet,

Are you also new to coding ? If so, then don't start with threads, that's a pretty complex subject that you should take on later after getting the basics correctly.

Also, for what you described there's no need for threads. Qt's asynchronous nature already provide what's needed.

Start with Qt's documentation. It also contains the Threading Basics

On a side note, it's Qt, QT stands for Apple QuickTime which you might also be interested in.

@SGaist

you should have to modify QAbtractSocket

Seems like you right. The code in 'qabstractsocket.cpp':

<...skipped...> // Start the connect timer. if (threadData->hasEventDispatcher()) { if (!connectTimer) { connectTimer = new QTimer(q); QObject::connect(connectTimer, SIGNAL(timeout()), q, SLOT(_q_abortConnectionAttempt()), Qt::DirectConnection); } connectTimer->start(QT_CONNECT_TIMEOUT); } <...skipped...>

And there are no options to disable it. But I think it will be easy to patch it to make it work without connectTimer.

But use a single timeout for thought of sockets ? Sounds strange.

What else can I do to avoid handles exhaustion? I don't see any other options.

Out of curiosity, why do you need so many sockets ?

Just testing Qt abilities and limitations in this particular area.

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'd say probably, but right now I don't know what might be interfering here to trigger that message.

@returnx
Ok. super. please mark as solved :)

Final note:
When you deploy,
there might be more reads for full json string.
The code you shown, will try to parse on each read. Make sure the code can
handle that it comes in blocks and not bail out if parse fails.

A TCP/IP connection utilizes two ports, the one you connect to on the remote end and a local port that is used for incoming data. The local port is an ephemeral port assigned by the operating system from the pool of free ephemeral port numbers. This is normal operation, you do not need to have a fixed local port because the the ephemeral port is sent to the remote end so that it knows how to reply to you the client.

QAbstractSocket::peerPort() returns the remote port number.

The code is good but the comment is false, it's not the parent that will delete socket, it's the event loop at the next occasion.

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.