2

I want to set different timeouts for different requests. My request routine looks like:

var request = URLRequest(url: url,
                         cachePolicy: .reloadIgnoringLocalCacheData,
                         timeoutInterval: timeout)
// setting headers and body...
sessionTask = localURLSession.dataTask(with: request)
sessionTask?.resume()

where localURLSession is defined as public var:

public var localURLSession: Foundation.URLSession {
    return Foundation.URLSession(configuration: localConfig, delegate: self, delegateQueue: nil)
}

public var localConfig: URLSessionConfiguration {
    let res = URLSessionConfiguration.default
    res.timeoutIntervalForRequest = Self.ordinaryRequestsTimeout // 20 seconds
    return res
}

Then I have 2 problems:

  1. When I make 2 simultaneous requests with 100% loss Network Link Conditioner (first with 20 seconds timeout and second – with 40 seconds), both requests fails after 8 seconds. I don't understand why.
  2. When I make one request for the first time with 100% loss Network Link Conditioner, it fails in timeout like expected, but retrying this request fails in 1 second. I want to wait all the timeout every time.
Valentin Shamardin
  • 3,569
  • 4
  • 34
  • 51
  • timeout is usually triggered when you have a poor reception on the device and not all of the data arrives back in the designated time-frame, meanwhile if you don't have reception at all it will fail immediately in general – it could be a few more other factors under the hood which may alter the core logic in the current context, but in principle that is what you need to prepare for. – holex May 07 '19 at 07:38
  • @holex, so my request setup is correct? But testing with 100% loss is not pure, and I need to make my own link conditioner filter? – Valentin Shamardin May 07 '19 at 07:57
  • that seems correct to me but it is also worth to mention that scenario _"100% loss"_ is not equal to scenario _"no reception"_ – you can have good reception but would still get 100% loss (e.g. because of server side issues, etc...) in practice; if it is important to re-try connecting automatically, you may need to worry about monitoring the network conditions as well and when it comes alive again your app automatically could trigger the request again... everything depends on how much sophisticated networking your services would require to satisfy your end-users eventually. – holex May 07 '19 at 10:16

1 Answers1

1

In all likelihood, for the 8-second failure, the DNS request is timing out, so you aren't connecting at all.

For the 1-second failure, the OS has probably concluded that the host is unreachable, and won't even try again until the network changes or it successfully makes at least one request to some host somewhere (negative DNS caching).

That said, without a packet trace, I can't be certain of either of those statements.

dgatwood
  • 10,129
  • 1
  • 28
  • 49