Re: Does CFSocket use efficient polling?
Re: Does CFSocket use efficient polling?
- Subject: Re: Does CFSocket use efficient polling?
- From: Mark Pauley <email@hidden>
- Date: Mon, 16 Feb 2009 13:30:17 -0800
Sorry, my mistake that was 100 ms or .1 seconds. 30ms is closer to
various other socket timeouts we've got, it would be ridiculously long
for an 'expected' timeout like this. So NSURLDownload has a "low-
watermark" socket buffer.
Select() on the underlying socket will not return until we've received
either k bytes (roughly 1 megabyte it turns out on MacOS, this can and
will change... don't count on the number) where k is the low-water
mark or it's been n seconds, whichever happens first. In that case,
you might well receive the last q bytes (q < k) only after the kernel
timeout (the 100ms timeout) fires. The timeout value can and will
change in future releases as well, please don't count on that value
either.
Unfortunately there is no available API to give your NSURLConnections
the low-watermark characteristics. This only works if you're okay
with downloading the response directly to a file. If there is enough
interest in such a switch, we might investigate some sort of "low-
priority" URLConnection option flag that you could pass to the
NSURLConnection upon initialization and prior to starting the load.
Again, to get the low cpu footprint functionality, use NSURLDownload.
On Feb 16, 2009, at 1:09 PM, Dave Camp wrote:
This is excellent news.
Could you explain in a bit more detail the "30 seconds on the final
bit of data" part? Under what circumstances might this occur?
Thanks,
Dave
On Feb 16, 2009, at 12:06 PM, Mark Pauley wrote:
Wait, what OS are you seeing this on? We should have a much more
efficient CPU footprint on recent Leopard updates. We actually
tuned the socket callback with a low-watermark optimization. Turns
out we were getting a ton of callbacks because our socket buffer
was a bit too small, downloading (even on gig-e) should be much
nicer now. The catch is that the NSURLDownload code actually
exercises some code that NSURLConnection doesn't, and you pay for
the decreased CPU load with possible latency (almost guaranteed 30
seconds on the final bit of data I think). This works great for
things like streaming video and downloading.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_Mark
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden