I dont know why, but if I set the conexion between server and client first and then I call the function startSerialPort(), the reading speed is the normal. But this method just works with the first conexion. The second conexion already experiment the decrease of the reading speed.

void MyServer::startSerialPort() { mipuerto2 = new MySerialPort; msgRec = new MensajeRecibido; msgSent = new MensajeEnviar; connect(mipuerto2, SIGNAL(msgChanged(QByteArray*)), this, SLOT(getMens(QByteArray*))); connect(mipuerto2, SIGNAL(msgChanged(QByteArray*)), this, SLOT(idMensaje(QByteArray*))); connect(msgSent, SIGNAL(tienesMensaje(QString*)), this, SLOT(setRecibido(QString *))); mipuerto2->openSerialPort(); } qDebug()<<socketDescriptor<<"Connecting... "; socket = new MySocket(socketDescriptor); controlador++; QThread *thread = new QThread; qDebug()<<thread->currentThreadId(); connect(this, SIGNAL(mensChanged(QByteArray*)), socket, SLOT(getMsg(QByteArray*))); connect(socket, SIGNAL(mensajeEnviarSocket(QByteArray*)), this, SLOT(sendMens(QByteArray*))); connect(socket, SIGNAL(disconnected()),thread, SLOT(quit()) ); connect(socket, SIGNAL(disconnected()), socket, SLOT(deleteLater())); connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater())); connect(thread, SIGNAL(started()), socket, SLOT(funcionamiento())); connect(socket, SIGNAL(disconnected), this, SLOT(desconectar())); socket->moveToThread(thread); thread->start(); if(controlador==1){ startSerialPort(); }else if (controlador>1) { mipuerto2->closeSerialPort(); delete mipuerto2; startSerialPort(); }

@koahnig You were right, changing the pointer this to socket in the connection function of readyRead, it worked. Thanks you

@jsulm Hi, thanks for your answer and sorry for my delay, I haven't login in the forum during the weekend. You are right, I eliminated this line and I didn't get this trouble.

@fcarney
You were right. I changed the line where I initialize the serialport to a position before the connect and that works. Thanks!

@silau It looks good but ldd doesn't always report exactly what is actually happening when you run your exe. It's a good start though. If you really wanted to trace it further you would have to ldd on each of those libs to see what they link. One of them could be using the 5.6 or whatever other version you may have. That being said I find that to be a bit unlikely though.

When I get a little bit of time later today I will run your code using Arch linux and 5.11 and see what happens. That will help determine if maybe it's a bug in Qt (which I highly doubt for something that big).

If it works for me the next steps for you would be to run it in the debugger and step through the working 5.6 one during socket connections and then the broken 5.11 one and see what is different.

Another option is take it down to the simplest form and just use the chat example or something from Qt and see if it works with 5.11 and then try to see what is different.

I'll let you know what I find out on my linux/Qt 5.11 in a bit.

Edit: Didn't get a chance today, was really busy. I will run a quick test tomorrow some time though.

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

@aha_1980 said in Problem with QTcpSocket:

Hi @JCBaraza,

I hope you are well aware that the waitForReady... functions can only be used in threads.

If you don't have a thread (beside the main thread), you must use signals&slots, like the Fortune Client example.

Hi aha1980,
Thanks a lot for your quick answer. No, I'm affraid I didn't know about that. When I saw the Qt examples with sockets, I rapidly discarded using signals and slots because this kind of programming is a bit puzzling to me (just have a look to my code ;-) ). Well, I'll have to revisit Qt examples and get familiar to signals and slots outside the main window of my application.
Regards,

@g.hirsch
I'm not sure, but you can change port number 1883 to something else and check again. It's possible on some systems this port to be in use.
By the way, first error means this:

The requested socket operation is not supported by the local operating system (e.g., lack of IPv6 support).

@Gianluca86 said in QTcpSocket state always connected:

But the state doesn't change.

Pretty sure it does https://code.woboq.org/qt5/qtbase/src/network/socket/qabstractsocket.cpp.html#2788

In fact you can connect to stateChanged signal to check that

I've posted an answer how to know if you have read everything here: https://stackoverflow.com/a/46162082/969016

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.

I found a solution : I used the waitForReadyRead() function.
I still don't know why my code didn't work.

Edit : I found that I forgot to connect the slot with the signal, but even with that, it didn't work...

You're welcome !

Since you have it running now, please update the thread title prepending [solved] so other forum users may know a solution has been found :)

Also, consider up-voting answer(s) that helped you, it will make them easier to find for other users :)

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.

Hello,
Few issues with Your code:

QThread constructor moveToThread( this); is error. QThread class is just control object and is not actually a separate thread. You should move class base on QObject (with would be wrapper for QTcpSocket communication) or QTcpSocket to separate thread.

2.. Don't know if this is Ui application but You are using blocking approach (may be ok for Your case)

Error handing :

connect (QTcpSocket, SIGNAL( error(QAbstractSocket::SocketError socketError)), this, SLOT( error(QAbstractSocket::SocketError socketError)));

to handle connection error.

Close socket via QTcpSocket::close() or abort() + close()

@t3685 Yes I'm sure.

I just wanted to tack a me-too on here. I've been converting a QTcpServer app over to 64-bit and it immediately stopped receiving signal. Connecting a 64-bit client to a 32-bit server still worked, so the problem had to be in the 64-bit server or one of the dependencies. As it turned out, the incomingConnection() had an int argument instead of a qintptr, a change we missed when upgrading to Qt5.

Ok, i got it:

// Disambiguate overloaded member function below with static cast connect(socket, static_cast<void (QTcpSocket::*) (QAbstractSocket::SocketError)>(&QTcpSocket::error), this, &Network::socketErrorSlot);

I think that deserves to be in bugtracker, isn't it? Not good idea to implement new notation and use the same names for method and signal.