The server page was not loading and the issue was I was using the server's newConnection() signal to immediately write the html page to the client. But you have to wine and dine the client first. I ended up connecting the newConnection() signal to a set up function:

void Server::handleConnection() { QTcpSocket* client = nextPendingConnection(); //client->setSocketOption(QAbstractSocket::KeepAliveOption, 0); QObject::connect(client,&QTcpSocket::readyRead,this,[=](){ handleRequest(client); }); }

You can then write the HTML content to the client in handleRequest()

@Narutoblaze
Then no you cannot, as you can see in the documentation for QTcpSocket/ QAbstractSocket. If there were a method which took a "connection name" you would see it documented.

There is nothing to stop you writing your own code to store connections indexed by some "connection name" you choose, e.g. using a QMap Class.

@Narutoblaze
Your code/algorithm is incorrect. This is basic coding, please study what your code does. You "actively" encourage reading across file boundaries, i.e. what you call "too much").

You (seem to) start by setting size to the total number of bytes expected for the file. Then you call read(buffer, size);. But when that returns with fewer bytes than size you still call it again next time round asking it to read up to size further bytes. This can/will exceed the number of bytes in the first file. You obviously need to reduce what size you pass to read() accordingly on subsequent calls. And then be careful what you compare in your if (... || numReadTotal == size). Adjust your code however to make it right.

I previously said that the whole synchronous approach of repeatedly calling waitForReadyRead() in a loop is not the event-driven way to do things. Allow bytes to arrive in repeated readyRead() signals asynchronously instead.

You need to create an AJAX client in your web-page. You could do this with a JavaScript timer that periodically requests data via a GET request to your application. Your application would need to listen for these requests using a TCP socket then respond.

Depending on the amount of data you are going to be sending back to the client you may want to consider changing the method to a POST instead of GET as GET is limited in the data response to the URL length.

You will also need to have a web-server, you could build a web-server into your application using TCP sockets, if not use Apache or something else for prototyping.

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

@AlexisLara19 said in QTcpSocket to PLC S1200:

but don't works fine

What are the issues?
The problem is that you cannot use it with Qt?
Are you able to use it standalone?

@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 >
319d7357-9211-4008-ad08-dde32da2cfc0-image.png
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!

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.

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

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 :-)

As @SGaist pointed out you don't fill _sockets anywhere and as I pointed out you don't need to search the socket in _sockets at all since you already cast QObject::sender() to the correct QTcpSocket although qobject_cast or dynamic_cast should be used instead static_cast

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

@CP71 Dont worry, you are helpful. I will tried to find the trouble, I know that must be in my Code of the server, because in the first Code that I published in this thread I could do It. And in a simpler Code for just one connection server-client It also worked.

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

@SGaist I tried ffmpeg and vlc sadly with those libraries there were 2 seconds of delay. I want stream to be realtime. Plus my friend needs to access each frame in order to process it. With QT we can do such thing thanks to QByteArray and QBuffer.