Re: Architecture for concurrent network client
Re: Architecture for concurrent network client
- Subject: Re: Architecture for concurrent network client
- From: Sixten Otto <email@hidden>
- Date: Mon, 21 Sep 2009 17:36:21 -0400
On Mon, Sep 21, 2009 at 4:58 PM, Jens Alfke <email@hidden> wrote:
>> connections available to the application. Somehow I need to track
>> which/how many connections are idle, and dequeue requests to those
>> connections.
>
> Just keep a mutable array of free connections.
As I think about it more, I think you may be right.
I think I got stuck thinking that access to this stuff was going to
need to be thread-safe, for some reason. (Maybe because I was worried
about overhead in initiating the download blocking the UI?) But if the
I/O handling is all asynchronous, then it's probably the case that the
access to the connection pool can all happen on the main thread:
- When the user adds a download request: if there are available
connections, dequeue one and give it the request; otherwise enqueue
the request.
- When a request completes: if there are queued requests, dequeue one
and give it to the connection; otherwise, enqueue the connection.
> Do you have control over the protocol used by the server?
No. And, in actual fact, it's NNTP, which is about as far from
"efficient" as you're gonna get. (I left that part out because I
didn't want to sidetrack too much into the I/O specifics.)
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