The edited part of @JonB is important, you have to read the data.

after removing the lines:- auto img = QImage::fromData(rawimg); QLabel *myLabel = new QLabel; myLabel->setPixmap(QPixmap::fromImage(img)); myLabel->show(); it works perfectly with more than 20*3 images

Maybe that QByteArray is the culprit, you could try rewrite into more vanilla standard: ... { QByteArray block; QBuffer buffer(&block); buffer.open(QIODevice::WriteOnly); QDataStream out(&buffer); ... at least you would expose more stuff to the debugger :-)

@aha_1980 ok, thanks help again. regards.

Hi, You have a porting guide here in Qt's documentation.

@healermagnus said in QSslSocket and QTcpSocket ... how to know if the connection is incorrect: Any ideas what I'm missing? You want a delayed handshake. Ideologically it goes like this: You create the QSslSocket object, but operate it as a QTcpSocket. The server and client exchange TCP messages (as per your liking) to try and negotiate whether they should stay in plain TCP or in SSL mode. When the connection is decided to be used over SSL the client calls startClientEncryption, while the server socket calls startServerEncryption to begin the actual SSL handshake. Connecting the TCP error and sslErrors() signals is a must.

@aha_1980 ok, i understood what you said.

QTcpSocket socMeteo; QTextStream texte(&socHauteur); These are 2 different sockets. What are you trying to do? It should be something like: auto socMeteo = new QTcpSocket(this); socMeteo->connectToHost("192.168.1.35",10001); connect(socMeteo,&QTcpSocket::connected,socMeteo,[socMeteo]()->void{ QTextStream texte(socMeteo); texte<<"Bonsoir\n"; });

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,

I saw this old thread of mine and remembered, that the issue was solved. Just writing to explain how I solved it. The problem was in the proxy settings. People who had their proxy configuration to automatic could connect, everyone else could not. First solution was to set the configuration to automatic on every client. Which was cumbersome and seemed stupid, because the program does not need any proxy. A little later I found out, that there was a problem with the Qt Network Interface, it was a known bug and could be worked around by telling the program manually to not use any proxy: /* call before connecting to network. Easiest way is, just call somewhere at the beginning of the program */ QNetworkProxy::setApplicationProxy(QNetworkProxy::NoProxy);

@KroMignon said in QTcpSocket state always connected: result = setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &enableKeepAlive, sizeof(enableKeepAlive)); result = setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &maxIdle, sizeof(maxIdle)); result = setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &count, sizeof(count)); result = setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &interval, sizeof(interval)); TCP_KEEPIDLE / TCP_KEEPCNT / TCP_KEEPINTVL - linux options, aren't they? So for windows I found next solution: add this lib to your project *.pro file LIBS += -lws2_32 Next after socket connection you should use: #include <Ws2tcpip.h> //------ // socket is QTcpSocket* if (socket->state() == QAbstractSocket::ConnectedState) { int fd = socket->socketDescriptor(); DWORD dwBytesRet = 0; struct tcp_keepalive alive; // your options for "keepalive" mode alive.onoff = TRUE; // turn it on alive.keepalivetime = 30000; // delay (ms) between requests, here is 30s, default is 2h (7200000) alive.keepaliveinterval = 5000; // delay between "emergency" ping requests, their number (6) is not configurable /* So with this config socket will send keepalive requests every 30 seconds after last data transaction when everything is ok. If there is no reply (wire plugged out) it'll send 6 requests with 5s delay between them and then close. As a result we will get disconnect after approximately 1 min timeout. */ if (WSAIoctl(fd, SIO_KEEPALIVE_VALS, &alive, sizeof(alive), NULL, 0, &dwBytesRet, NULL, NULL) == SOCKET_ERROR) { QDebug() << "WSAIotcl(SIO_KEEPALIVE_VALS) failed with err#" << WSAGetLastError(); return; } }

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