On Tue, Jan 20, 2009 at 9:17 PM, Michael Vannorsdel <mikev...@gmail.com>wrote:
> I've looked into this quite some time ago and have seen NSURLConnection > keep FTP and HTTP connections open even after the originating > NSURLConnection had been deallocated. The same connection was reused for > subsequent NSURLConnections to the same destination. I never did see these > close though so I don't know their lifetimes. All I know is they lasted at > least 5 mins. > Currently with iPhone Simulator, it seems 30 seconds. I am wondering why this is not documented. Note the time it is open, but there is a possibility that the connection may not be closed immediately. Wouldn't it make simpler ? At least to avoid flames :-) > > This came about because I saw the connections still open after the request > had ended and was debugging to see why they were stuck open. Never did > figure out how to force them to close. > Once you lost control from the application, you better be sure that the framework underneath is not buggy :-) -mohan > > > > > On Jan 20, 2009, at 9:45 PM, Michael Ash wrote: > > *Do* *not* *make* *assumptions*. >> >> You're making a huge assumption here: >> >> A) NSURLConnections must be reused in order to have persistent HTTP >> connections. >> >> And then we have this simple fact: >> >> B) There is no way to reuse an NSURLConnection. >> >> Putting these two together, we have a conclusion: >> >> C) NSURLConnection does not allow persistent HTTP connections. >> >> Since conclusion C is pretty much absurd, it would follow that perhaps >> assumption A is wrong. >> >> But don't assume. *Test*. Write some code and then use a network >> sniffer to see if, in fact, persistent connections are being used. >> >> If you don't know how to use a sniffer, this is your golden >> opportunity to learn. Doing network programming without a sniffer is >> like doing carpentry without any eyes. A particularly talented person >> might get astonishingly far without them, but he's still going to >> suffer from a severe handicap relative to a person who can actually >> see. >> >> Above all, please don't come barging onto the mailing list asking >> about a half-baked solution for a problem that you haven't even >> verified the existence of. >> > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/suruti94%40gmail.com > > This email sent to surut...@gmail.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com