Alamofire: What's different between timeoutIntervalForRequest vs timeoutIntervalForResource?

Created on 23 May 2016  路  5Comments  路  Source: Alamofire/Alamofire

I've read the document but doesn't understand.

timeoutIntervalForRequest
This will cause a timeout if no data is transmitted for the given timeout value, and is reset whenever data is transmitted

timeoutIntervalForResource
This will cause a timeout if a resource is not able to be retrieved within a given timeout

What do these mean?
I understand the first one, if there's no data is transmitted for the given timeout value.
But the second one, what is "resource" ?

If i want to set timeout is 20 second, during this time if the server is unreachable, it will be timeout, the first value is a correct choice?

question

Most helpful comment

Hi @Tom29,

Good question. Let me try to provide some details.

TimeoutIntervalForRequest

The max time interval to wait between server responses before cancelling the request. All session tasks use this value, but it is really designed for tasks running on a default or ephemeral session. Tasks running on a background session will automatically be retried.

Unless you are using background sessions or download massive payloads, this is most likely the only property you need to worry about.

TimeoutIntervalForResource

The max time interval allowed for downloading a request payload. The default value is 7 days. While this can be used for default and ephemeral sessions to specify something like no request should take more than 5 minutes to complete, it's really intended for upload and download tasks running on a background session. Background URL sessions will automatically retry failed tasks behind the scenes until the timeoutIntervalForResource is reached. You won't receive a failure until this interval is reached for background sessions.

Hopefully that helps clarify things.

Cheers. 馃嵒

All 5 comments

Hi @Tom29,

Good question. Let me try to provide some details.

TimeoutIntervalForRequest

The max time interval to wait between server responses before cancelling the request. All session tasks use this value, but it is really designed for tasks running on a default or ephemeral session. Tasks running on a background session will automatically be retried.

Unless you are using background sessions or download massive payloads, this is most likely the only property you need to worry about.

TimeoutIntervalForResource

The max time interval allowed for downloading a request payload. The default value is 7 days. While this can be used for default and ephemeral sessions to specify something like no request should take more than 5 minutes to complete, it's really intended for upload and download tasks running on a background session. Background URL sessions will automatically retry failed tasks behind the scenes until the timeoutIntervalForResource is reached. You won't receive a failure until this interval is reached for background sessions.

Hopefully that helps clarify things.

Cheers. 馃嵒

@cnoon If I create the SessionManager with background configuration, but the app never goes to the background, does the TimeoutIntervalForRequest still work?

"Background URL sessions will automatically retry failed tasks behind the scenes until the timeoutIntervalForResource is reached"

@cnoon is there any way to cancel this behavior of retrying failed tasks, and fails fast

Hi @AlaaAlHallaq, to clarify a bit, the background session will only continue to retry requests if there were errors with the connection and it fails to hit the server. It will not keep retrying once it hits the server and downloads all of the data. If it only receives part of the data before the connection is lost, it will wait in the background until the connection is restored and fire it back up trying to resume the download from where it stopped. That may or may not work which would either resume the download from where it left off, or it would start over.

Hopefully that helps clarify things a bit. My apologies for being a bit vague about that in my original answer.

Cheers. 馃嵒

@cnoon
Thanks for the clarification, but my question remains, can I make a hit and run request, where if any error happened, just report back to me in the callback, and don't wait until any time out occur !

Was this page helpful?
0 / 5 - 0 ratings