Re: NSData downloaded over socket is bigger than it should be...
Re: NSData downloaded over socket is bigger than it should be...
- Subject: Re: NSData downloaded over socket is bigger than it should be...
- From: Jean-Nicolas Jolivet <email@hidden>
- Date: Fri, 19 Dec 2008 01:04:35 -0500
Hehe I understand, I didn't give much info ...
the thing is, AsyncSocket works mostly with delegate methods so it's
kinda hard to paste some code (i.e. it's not like I have only 1
NSURLConnection didReceiveData: call...it's a complex setup with a
bunch of simultaneous connections, a ConnectionArrayController, and a
lot of delegate methods etc...)
but basically this is how I'm doing it (i'm downloading attachments
on a newsgroup server)
To download a news article I need to send "ARTICLE <article title>\r
\n" so I do:
NSString *downloadString = [NSString stringWithFormat:@"ARTICLE %@\r
\n", articleTitle];
NSData *downloadStringData = [downloadString
dataUsingEncoding:NSASCIIStringEncoding];
[asocket writeData:downloadStringData withTimeout:-1
tag:S_ARTICLE_DOWNLOAD];
Once I get confirmation that this has been sent (via a delegate
method) I read until the following data is found: "\r\n.\r\n" (this
delimits the end of a message)
How do this like that (in this case, endDelimiter = [[NSData alloc]
initWithBytes:"\x0D\x0A\x2E\x0D\x0A" length:5]; )
[sock readDataToData:endDelimiter withTimeout:-1
tag:S_ARTICLE_RECEIVED];
Now, once the data is downloaded, the following delegate method is
called:
-(void)onSocket:(AsyncSocket *)sock didReadData:(NSData*)data withTag:
(long)tag
{
if(tag == S_ARTICLE_RECEIVED)
{
// data is received and contained in the "data" variable...
}
}
At this point I could just write the data to disk using [data
writeToFile:] or something similar... binary files posted on
newsgroups have to be encoded though (because nntp protocol only
support ASCII) so they are usually encoded with yEnc, UUEncode or
Base64.... also they are usually split between multiple segments...
the good thing is that, the decoder (wheter it's yEnc decoder,
UUDecode or whatever) joins the part so I don't have to deal with that
(i.e. I don't have to concatenate or "join" the data myself)...
All I have to do is grab the whole article and save it on the disk...
(so basically, the "data" that is sent to the didReadData delegate
method...) but, when I write this data to the HD, (using [NSData
writeToFile:]) this is where I get extra bytes (usually around 10-14
extra bytes per segments)...
It's a bit hard to track because the setup,as I said, works with
multiple simultaneous connections etc, but it's really straight
forward: ONE socket downloads ONE segment and save it to disk... the
decoder deals with putting all the segments together once all the
segments of a file have been downloaded... but most segments have
extra bytes in them...
And to make it workse, sometimes (usually when I grab stuff like
images or smaller stuff like that which consist of only 1 segment)
then they end up just fine... the extra bytes are only present with
bigger attachment (of 1mb+) and especially with multiparts
attachments...
Jean-Nicolas Jolivet
On 19-Dec-08, at 12:41 AM, Michael Ash wrote:
On Thu, Dec 18, 2008 at 7:01 PM, Jean-Nicolas Jolivet
<email@hidden> wrote:
Well this is going to be a bit vague since my situation is a bit
specific
but basically I am downloading data using AsyncSocket... then I'm
saving it
directly to the HD...
However in like 80% of the cases, the resulting data on disk is
slightly
bigger (usually around 12 or 13bytes) than it should be (according
to the
crc32)
I am downloading multiparts email attachments (encoded via either
uuencode,
yEnc or Base64)... and the corresponding decoder always complains
of bad CRC
checks when I try to decode the downloaded data...
It's always a *tiny* amount of bytes (but not a constant amount) so
for
example if I downloaded an Mp3 file, the resulting decoded data
will play,
but with little glitches every here and there (probably where the
parts were
joined)....some examples of the decoder's otuput:
Part 1.rar: Decoded size (384012) does not match expected size
(384000)
Part 2.rar: Decoded size (384013) does not match expected size
(384000)
...
Now as I said, I know this is really vague, but did anyone experience
something similar with AsyncSocket or any other sockets? or NSData
altogether??
Definitely need more info for this:
- What code do you use to download the file?
- What code do you use to write the file?
- Where are the excess bytes located in the file?
- What do the excess bytes contain?
You're right that this is kind of vague, but a vague description with
a bunch of specifics will be much easier to work with!
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Jean-Nicolas Jolivet
email@hidden
http://www.silverscripting.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden