[Solved] Read from QSslSocket results irregular data

dynup

Hi guys,

I read from a QSslSocket to receive yenc encoded usenet articles and save it to files, but something is wrong. Some articles have wrong CRCs while decoding (one "Segment" for each article and file):

@
QSslSocket *sslSocket;
QFile output;

void Segment::socketReadyRead() {
const QByteArray data = sslSocket->readAll();

output.write(data);

if (data.contains("=yend")) {
    sslSocket->close();
}

}
@

What is wrong with my code? Someone has a hint for me?

Thanks!
Kai

DerManu

How do you calculate the CRC? How do you do the yEnc decoding? Is it possible that there is data before =ybegin and after =yend?
For example, if readAll() returns "[data]=yend\n" you'll add the whole =yend\n part to output, which might not be expected by the decryption algorithm, and thus corrupt your last data segment.

dynup

The yenc encoding process works after all articles are downloaded, each article in one file. The yenc decoding class works 100% (with correct CRCs), if I download all articles with another program (newsreader/grabber etc.), the yenc decoder decodes it with no errors! ...therefore the problems are in my downloading code!

tolszak

I suggest to add some qDebug() and check if corrupted files have more that one call of Segment::socketReadyRead().

Is it pseudocode?
Why don't you open file before writing with QIODevice::Append mode?
You don't call flush and close on QFile so it's not sure that all data is written to device(some device buffer etc).

dynup

It's not a part for this sample here. File will open before connect to host and closed after socket is closed (in other functions)! Segment::socketReadyRead() is called multiple times of course, it's a TCP based connection.

DerManu

I still wonder whether there's data after "=yend", since you just use readAll and push that into output without truncating after "=yend"...

dynup

=yend is part of last data block, after this article ends.

Last line of each article is:
=yend size=<...> part=<lastPartNumber> pcrc32=<crc>

dynup

Addition:

pcrc32=<8 char hexvalue> Representing the 8-bit CRC32 of the encoded binary part
crc32=<8 char hexvalue> Representing the 8-bit CRC32 of the encoded binary

dynup

I found the (simple) problem!

In NNTP protocol some lines (I read line by line now) begins with a double-dot, this must detect and replace with a single dot, that's it! All CRCs are conform now!

Thanks to all for help anyway!