[SOLVED] Writing more than 4096 bytes on a socket in once
i have the following problem.
I have written a server process where a client process (also written by me) connects to.
The server sends data to the client via QSslSocket which works fine as long as the data the sever sends does not exceeds 4096 bytes.
The client @bytesAvailable@ slot is called and i always see that there are 4096 bytes available.
But the server has sent much more.
I understand that TCP can fragment data which is okay.
My client side code looks like this:
qDebug() << "Sync::readyRead: bytes available=" << m_tcpSocket->bytesAvailable();
const QByteArray data&(m_socket->readAll());
readyRead() gets called more times (which is okay because of tcp fragmentation).
My question is there a way (without implementing a protocol which holds the size information in header for example) to know on the client side that there is still data available?
I can not predict how ofter readyRead get called.
Hmm. i think i have to implement a protocol somehow....
Or any other ideas?
You can check with a while loop if there is more data to read in your readyRead function. To my understanding the problem is that the new readyRead signal is not issued when you are in the assigned slot routine.
So any signal issued while reading will be ignored. With the while loop you will continue to read until there is no further data. When more data comes after you have exited the routine you should have another signal coming in anyway.
Alternatively, you can call the readyRead slot externally with a delay or use a single shot timer.
i tried it with a while loop like:
... raed data....
But it is not working.
bytesAvailable gives back 0 and short time after byteAvailable is called again.
I solved it now by adding a small protocol.
Just the size in top of the message.
I wrote to methods:
which adds the <size> in front of the stream
which removes the <size> from the beginning of the stream
Then i have a small logic which waits until <size> bytes were read and then starts processing the message instead of direct start processing after first @socket->readAll()@ call in @bytesAvailable()@ slot
This seems to work fine.