Architecture for concurrent network client
Architecture for concurrent network client
- Subject: Architecture for concurrent network client
- From: Sixten Otto <email@hidden>
- Date: Sun, 20 Sep 2009 08:43:00 -0700
I'm trying to work out in my head the best way to structure a Cocoa
app that's essentially a concurrent download manager. There's a server
the app talks to, the user makes a big list of things to pull down,
and the app processes that list. (It's not using HTTP or FTP, so I
can't use the URL-loading system; I'll be talking across socket
connections.)
This is basically the classic producer-consumer pattern. The trick is
that the number of consumers is fixed, and they're persistent. The
server sets a strict limit on the number of simultaneous connections
that can be open (though usually at least two), and opening new
connections is expensive, so in an ideal world, the same N connections
are open for the lifetime of the app.
I've looked over the Apple's Concurrency Programming Guide
(http://developer.apple.com/mac/library/documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html),
and done some searching around on web and Stack Overflow, but not
finding a lot of information that seems directly applicable, because
of those constraints.
One way to approach this might be to create N threads, each of which
would "own" a connection, and wait on the request queue, blocking if
it's empty. Since the number of connections will never be huge, this
is not unreasonable in terms of actual system overhead. But
conceptually, it seems like Cocoa must offer a more elegant solution.
It seems like I could use an NSOperationQueue, and call
setMaxConcurrentOperationCount: with the number of connections. Then I
just toss the download requests into that queue. But I'm not sure, in
that case, how to manage the connections themselves. (Just put them on
a stack, and rely on the queue to ensure I don't over/under-run? Throw
in a dispatch semaphore along with the stack?)
I'd been thinking that Grand Central Dispatch might open up some other
ways of tackling this, but at first blush, it doesn't seem like it.
GCD's flagship ability to dynamically scale concurrency (mentioned,
for example, in Apple's guide's recommendations on Changing
Producer-Consumer Implementations) doesn't actually help me. But I've
just scratched the surface of reading about it.
Can anyone recommend other lines of inquiry? Or good examples of this
kind of concurrent operation?
Sixten
_______________________________________________
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