Thanks for answering. Indeed I found a pattern and probably the explanation, now I need to found the appropriate solution: What happen is that My iphone application presents the data that comes as an xml files, which I fetch from a various urls on the same server. There are problematic urls, that when I try to reach them from safari or from within the application give an error - mostly timeout error. When I initialize the NSURLConnection I define a timeout in my NSURLMutableRequest in order not to stuck the GUI and let the user to work with application. On timeout I get didFailWithError in NSURLConnectionDelegate and show a message that there was not response from the server and the user can continue working. The matter is that the connection or underlying socket somehow is preserved and the connection with the server is not closed. So when I try to get another url from the same server I can't reach it since the server is still stuck with the previous problematic request! Now I can understand why from the other device or the browser I can reach urls, that are not reachable after problematic request on my device, simply because they open another socket to the same server. The question is how do I totally close (force closing) the problematic connection, that is stuck till the server will "get out" of this unsuccessful fetch? I tried close connection and cancel connection, but seems these APIs do nothing :(. Is the NSURLConnection way to go in such cases? Each time I need to get xml file I create another NSURLConnection. I read somewhere that it's not a good practice...
Again, thanks for the help. On May 29, 2010, at 5:04 AM, Jerry Krinock wrote: > > On 2010 May 28, at 02:58, Nava Carmon wrote: > >> When I enter same link in Safari it takes a second to bring data. > > I understand that you're saying it "works OK at the same time from the same > IP address from Safari", meaning that you have ruled out being throttled by > this "certain server", or your ISP. OK, because these would be the first two > suspects on my list. > >> And after another trial I can access the link. > > I'm assuming you mean exactly the same URL. Some servers give better service > to web browsers than to apps requesting via their API. > >> What might be the reason for such a weird behavior? How can I improve it? > > You're going to have to discover a pattern. For another data point with > these types of problems, you'll usually want to open a Terminal window and > send your request using the unix command curl(1). > >> What is the role of cache policy with NSURLConnection? > > Long answer: > > http://developer.apple.com/mac/library/documentation/cocoa/conceptual/URLLoadingSystem/Concepts/CachePolicies.html > > For consistency in testing, you'll probably want to use > NSURLRequestReloadIgnoringCacheData. > > Let us know if you find anything interesting. Actually, a better list for > this question would be [email protected]. > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/ncarmon%40mac.com > > This email sent to [email protected] Nava Carmon [email protected] "Think good and it will be good!" _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
