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