Reuse and lifetime of NSURLSessions
Reuse and lifetime of NSURLSessions
- Subject: Reuse and lifetime of NSURLSessions
- From: Greg Robbins <email@hidden>
- Date: Tue, 27 Jan 2015 17:50:07 -0800
What's an appropriate granularity for reusing an NSURLSession object? Specifically...
1. Should there be one session per host, or one session for all of an app’s fetches, or should each session be used for some set of hosts?
Session tasks don't appear to support keep-alive across different sessions. So it seems that it's mandatory to reuse a session for a sequence of fetches to the same server in order to avoid the overhead of having to reestablish a secure connection.
The main non-task session delegate method is for server challenges, which suggests a session is best targeted for talking to a single host.
But a session config allows specifying HTTPMaximumConnectionsPerHost, implying instead that a session should be used for multiple hosts.
The NSURLSession docs also handwavingly describe a session being appropriate for all fetches in a browser window, which would be to arbitrary, unrelated hosts. That would make the session delegate’s per-session handling of server challenges unlikely to be useful, since each host typically has unique authentication.
2. Is there value to reusing a session for as long as an app is running, or to invalidating a session when an app is not making network requests?
The documentation says to invalidate a session when it's no longer needed to avoid a memory leak of the retained delegate. But it's rare for an app to completely finish talking to servers. Is there a cost to the idle session aside from the retained delegate?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden