@duckrae List your client with id, when you are getting new incomingConnection. server can reply as per client id to a specific client or reply to all.

@J-Hilk thanks for your comment. I put that to read continuously from the buffer, but of course it is not necessary as soon as the signal/slot mechansim works.

@VRonin yes thats right. But the example here is simplified to the bone to track down that evil issue... Currently my server in release mode with profiler enable pushes around 3000 connections in 592ms, so 6k per second +/-... I've no idea if thats good or bad, But looking at profiler > The top green are new connection handlers, all it does is grab a handle > pushes it to vector. Its about 0.001 ms the second row is the creation of objects for each handle, which is done in worker and the "tall" one are all the pragma omp helping multithread different parts of app. Seems pretty fast given that in that time > accept connections, push them to monitor for display to show that there are new connections - this is batched too Set connections details from packed I received Validate connection credentials some more work. Yeah, I'm amazed o.o, but I have no idea if thats good/bad performance-wise. Learning networking here lol. Possibly 360k Connections /validations/ displaying per minute ? I can't spawn enough test connections per second to test how much can I push lol.

@jsulm Silly me, I always went straight to QAbstractSocket from that page... thanks!

@Dariusz said in How to properly delete threads& objects in them ?: So in general, moving object to another thread does not set the thread as it parent does it. No because the function is called moveToThread and not moveToThreadAndDoOtherStuffLikeSettingaParent

@Dariusz said in QtcpSocket states & disconnect signal: QAbstractSocket::UnconnectedState As per Qt Docs To close the socket, call disconnectFromHost(). QAbstractSocket enters QAbstractSocket::ClosingState. After all pending data has been written to the socket, QAbstractSocket actually closes the socket, enters QAbstractSocket::UnconnectedState, and emits disconnected(). First enters the state then emits the signal, In this case UnconnectedState state and then emits disconnected().

My dumb ass set the socket thread to nullptr 1 function before and then I was scratching my head why thread() was retuning QObejct(0x0) and I could not test against nullptr/etc... I'm gifted Sorted.

Solved. For some reason one of my QThread workers send a message on socket and did not post it to Socket thread... that caused it to internally "crash" without telling any1 about it and thus became "broken" internally. Once I posted it to correct thread everything started to work again... sigh! :- )

@BodyaGunko Hi and welcome. That's what running a web/HTTP server and exposing the IP over the Internet allows, from any client with a web browser.

@JonB sorry for late reply. you suggestion worked well. i followed https://wiki.qt.io/WIP-How_to_create_a_simple_chat_application and modified my code according to that. now at sender side looks like this QJsonDocument doc1; QFile j("/home/first.JSON"); if(j.exists()) { if(j.open(QIODevice:: ReadOnly| QIODevice::Text)) { jstr=j.readAll(); doc1= QJsonDocument::fromJson(jstr.toUtf8()); } j.close(); QDataStream clientStream(socket); clientStream.setVersion(QDataStream::Qt_5_7); // Create the JSON we want to send QJsonObject message; message[QStringLiteral("type")] = QStringLiteral("message"); clientStream << QJsonDocument(doc1).toJson(); } } else { ui->l_err->show(); ui->l_err->setText("Connection refused. Please check server."); } and used server application from the link above at receiver end. this works well. I have tested this with JSON file having 3000 object. Will this work for 50,000 samples and more possibly 1500000 objects?

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,

@Pablo-J-Rogina yes, and it doesn't say much more than what can be gleaned from the function signature. What is missing is any discussion of why one might want to call it (in normal circumstances that is, not to work around what apparently is a bug). Also, as I asked, whether calling it might have any adverse effects.

@puzzled_giraffe QTcpsocket have not got "connectState" setup? I think qt use long tcp connection by default.

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.