@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