Re: Maximum simultaneous NSURLConnections?
Re: Maximum simultaneous NSURLConnections?
- Subject: Re: Maximum simultaneous NSURLConnections?
- From: John Pannell <email@hidden>
- Date: Wed, 15 Mar 2006 21:53:31 -0700
Hi Greg-
Thanks for your response... it highlights some issues I need to
account for is design, particularly the DOS attack issue. (funny
sidenote - the ISP the hosts my website blacklisted my home IP after
I last night's testing of my new web spider engine for exactly that
reason... I promised not to point that gun at them again, and am now
testing against another apache box on my home network :-)
This does raise a new question, though, and I'm hoping someone has an
answer: Does every allocated NSURLConnection represent an actual
"connection", or does the URL Loading system hide that from us, and
coalesce multiple allocations into a single "connection" that it
manages internally? It seems, for example, that when loading a
graphically rich web page, the web kit internals must make hundreds
of individual resource requests, and it seems impossible that there
are only two resources "in transit" at a given time. I'm guessing
the URL Loading system hides the actual *number* of established
connections with the server from us (but I've guessed wrong before).
To better explain the "load balancing" I'm trying to achieve... In my
program, I maintain three queues (NSArrays) of objects: identify,
parse, and load. Three other arrays hold objects that are "in
process" for each category; when an object is in process, it uses an
NSURLConnection to fetch its content data. What I'm planning is to
set a total number of NSURLConnections as a cap (say the 64 that
Jerry recommended), but then dynamically size the in process arrays
to fit the situation. Say I started the app allowing 20
NSURLConnections for each queue... if it becomes clear during
processing that the parse queue never uses all twenty, I would shrink
its allocation of connections and give them to the other two. And as
it nears the end of the run and no more resources remain to identify
or parse, I would give all 64 connections to the load queue. That
was the intent of my first question - what should I set the cap at?
Thanks again for your response, Greg - please let me know if you have
additional thoughts...
John
On Mar 15, 2006, at 8:42 PM, Greg Herlihy wrote:
When connecting to a public HTTP server, a client should not
maintain more
than two open connections to that server at one time. (RFC2616
ยง8.1.4) An
HTTP server is likely to impose its own limit on the number of
simultaneous
connections from a single IP address anyway. Furthermore opening a
large
number of simultaneous connections to a server may be seen as a
denial of
service (DOS) attack upon the server.
Queuing HTTP 1.1 requests on a single, asynchronous connection such as
NSURLConnection is likely to offer the best throughput anyway -
since both
the requests and the responses can be "pipelined" (sent back to
back without
any pause between them). Furthermore, an asynchronous connection
makes the
most effective use of the client's processor cycles; because it
allows the
client to perform local processing (such as parsing HTML) more or less
continuously - and be interrupted only when data is available.
Generally, most HTTP requests are I/O bound - so transferring the
data from
the server to the client's machine in the shortest amount of time
achieves
the best performance. Client "load balancing" can only interfere
with that
goal. And in fact a client has no reason for balancing the load of its
requests - because unlike a server - it can (and should) simply
limit how
many outstanding requests it has to deal with at any one time.
Greg
On 3/15/06 2:50 PM, "John Pannell" <email@hidden> wrote:
Hi all-
I know there must be an answer to this, but I've yet to find it... is
there a way to determine the maximum number of simultaneous
NSURLConnections an application can keep open at one time?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden