Re: [Q] Comparison of Asynchronous handling of incoming data using "Descriptor Sources" in GCD and NSStream's Run-Loop scheduling?
Re: [Q] Comparison of Asynchronous handling of incoming data using "Descriptor Sources" in GCD and NSStream's Run-Loop scheduling?
- Subject: Re: [Q] Comparison of Asynchronous handling of incoming data using "Descriptor Sources" in GCD and NSStream's Run-Loop scheduling?
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Mon, 15 Oct 2012 17:33:28 +0100
On 15 Oct 2012, at 17:20, JongAm Park <email@hidden> wrote:
> May I ask if there is some rationale in choosing these two asynchronous handling of incoming data? : Descriptor Sources in GCD and Run-Loop scheduling of NSStream.
Here's some things to consider:
o existing architecture -- If you're already heavily invested in GCD queues, descriptor sources are an obvious choice. Likewise, if you already have a lot of structure based around run loop, NSStreams are your friend.
o high-level protocols -- If you need a high-level protocol that's implemented by higher layers of the stack, you should use that. For example, if you doing HTTP, you should use NSURLConnection or, if that's too restrictive, CFHTTPStream. These obviously fit in well with run loops.
o TLS -- CFSocketStream has TLS support built in. If you use GCD you have to implement that yourself, preferably based on Secure Transport. Glueing these two together isn't always easy.
o connect on demand -- Various connect-on-demand subsystems plug in at the CFSocketStream level, most notably VPN on Demand and WWAN on iOS.
o connect by name -- CFSocketStream supports connect by name, which has a world of advantages. Specifically, on 10.7 or later (or iOS 6 or later) CFSocketStream will automatically world over IPv4 or IPv6 depending on which has the best connectivity. GCD descriptor sources rely on you using BSD Sockets for that, and BSD Sockets is not nearly so clever.
o performance -- I haven't measured it, but I expect that GCD will be significantly faster, especially on networks that are fast enough to stress the device you're running on.
My one concrete recommendation is that you isolate your app-level code from your networking code so that you don't let implementation details like this spread throughout your app. Personally I use NSOperation for this. I structure my async code as an NSOperation subclass, then I can change how that works (run loops, threads, GCD) without having to rework my app at all.
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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