QTcpSocket package loss [SOLVED]
-
[quote author="Seraph" date="1351358440"]Yes, but how may i buffer smth which is simply not there?
And why is it there, when i do not reset the senders byte array after sending!? That is the point!
Did u test it yourself?[/quote]
Yes, I have tried to modify the example code.
Yes, you are right. Packages are apparently lost. I assume that the changes within the last releases due to QNetwork stuff are the reason. I could not find the reason right away.I have started using QTcpSocket much earlier than version 4.7 came up. It is not QTcpSocket's fault so. I would recommend using QTcpSocket and QTcpServer directly. The use of the QTcpSocket read and write on character basis is circumventing the QDataStream stuff. That is the way I am using it and it works.
-
The easiest is to get the fortune server example extended to do what you like to see, since I have no example code readily available.
I have started another trial. I have used very old example code for the fortune examples. It is from version 4.3.1 downloaded "from here":ftp://ftp.qt.nokia.com/qt/source/qt-all-opensource-src-4.3.1.zip .
The same string is sent just 1000 times in here.
@void Server::sendFortune()
{
QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_4_0);
out << (quint16)0;
out << fortunes.at(qrand() % fortunes.size());
out.device()->seek(0);
out << (quint16)(block.size() - sizeof(quint16));QTcpSocket *clientConnection = tcpServer->nextPendingConnection(); connect(clientConnection, SIGNAL(disconnected()), clientConnection, SLOT(deleteLater())); for ( int i = 0; i < 1000; ++i ) clientConnection->write(block); clientConnection->disconnectFromHost();
}
@[edit: post shortened, koahnig]
-
@
void Client::readFortune()
{
QDataStream in(tcpSocket);
in.setVersion(QDataStream::Qt_4_0);while ( tcpSocket->bytesAvailable() ) { if (blockSize == 0) { if (tcpSocket->bytesAvailable() < (int)sizeof(quint16)) return; in >> blockSize; } if (tcpSocket->bytesAvailable() < blockSize) return; QString nextFortune; in >> nextFortune; blockSize = 0; of << nextFortune.toStdString() << std::endl; } //if (nextFortune == currentFortune) { // QTimer::singleShot(0, this, SLOT(requestNewFortune())); // return; //} //currentFortune = nextFortune; //statusLabel->setText(currentFortune); //getFortuneButton->setEnabled(true);
}
@See readFortune and also the global fstream at the beginning. This version simply writes the received stuff in a file. I have tried to keep the changes as few as possible.
[edit, koahnig]
I did not expect that the source files are as long. Here are the changed "example files as zip on dropbox.":http://db.tt/ohgWvly0
-
The example code contains also the information received. It has 1000 lines.
The fortune example is excellent. However, it could be the closing of the connection throwing you of the track. This is just guessing. My server apps are simply keeping the socket and therefore, they are keeping the connection open. In that respect the fortune server is different. It is a simply question and answer application.
However, check the example code out. -
OOOOOOKKKK! I finally got it!
So for everybody who is confused of the results of fortune client example for QT 4.7:
In the new fortune client example they dropped the while loop, which is looping until no bytes are available! This one is working, when you send the messages with delay (Like in an intervall of 100ms) or like in the example only one message.
The problem is fixed by adding this while loop again (like in koahnig's example):
@
void TcpServer::readBytes()
{
while ( _socket->bytesAvailable() )
{
if (blockSize == 0) {
if (tcpSocket->bytesAvailable() < (qint64)sizeof(quint16))
return;in >> blockSize; } if (tcpSocket->bytesAvailable() < blockSize) return; QString nextFortune; in >> nextFortune; blockSize = 0; of << nextFortune.toStdString() << std::endl;
}
}@Thanks a lot to koahnig for figuring that out!!!
Bye and thanks again
-
Good to know that this solved your problem.
BTW the while loop is not in the original example of 4.3.1 either. That is part of my changes.
The fortune server sends the blockSize and the block afterwards. The modified server does send the original stuff a couple of times (1000 times in the example). So it sends the whole sequence repeated.
The part in the while loop reads only one block each time from the socket. The while loop ensures that the socket content is read completely up to the end. You have no influence when and how often the readyRead signal is triggered. It may be triggered after each block sent. However, if you are sending the blocks without or with short delay only, it is likely that the readyRead is not triggered for each block.
-Please mark the thread with [Solved] in the title.-
[edit, was too late with last remark, koahnig ;-) ]