TIC Read Status 1:60

App & System Services Networking
LanYueYuGeXing OP
Created Oct ’17
Replies 8
Boosts 0
Views 2.3k
Participants 2

Hi, I've met a strange problem: when device idle for about 2 mins, the next http request will always timeout with error:


  2017-10-10 10:30:32.116251+0800 Test[831:16324] error Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSUnderlyingError=0x600000441020 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, NSErrorFailingURLStringKey=https://itoutiao.sogou.com/v1/getnewslist?phone=1&pn=iPhone+6s&mode=up&h=6ED4FEA0-56AA-460A-B3A4-97A632A19CF8&api=7&count=15&mn=Apple&v=2.3.2&sys=iOS&appid=7784&b=%E6%8E%A8%E8%8D%90, NSErrorFailingURLKey=https://itoutiao.sogou.com/v1/getnewslist?phone=1&pn=iPhone+6s&mode=up&h=6ED4FEA0-56AA-460A-B3A4-97A632A19CF8&api=7&count=15&mn=Apple&v=2.3.2&sys=iOS&appid=7784&b=%E6%8E%A8%E8%8D%90, _kCFStreamErrorDomainKey=4, _kCFStreamErrorCodeKey=-2102, NSLocalizedDescription=The request timed out.}


then after a while, four lines of log are printed:


2017-10-10 10:30:46.120391+0800 Test[831:24327] TIC Read Status [1:0x604000175000]: 1:60
2017-10-10 10:30:46.120514+0800 Test[831:24327] TIC Read Status [1:0x604000175000]: 1:60
2017-10-10 10:30:46.121433+0800 Test[831:24327] TIC Read Status [1:0x604000175000]: 1:60
2017-10-10 10:30:46.121587+0800 Test[831:24327] TIC Read Status [1:0x604000175000]: 1:60


then the network is recovered.

Replies  8
Boosts  0
Views  2.3k
Participants  2
DTS Engineer OP
Apple
Oct ’17

FYI, in this log line:

2017-10-10 10:30:46.120391+0800 Test[831:24327] TIC Read Status [1:0x604000175000]: 1:60

the 

1:60
indicates an errno-style error (1) and that error is 
ETIMEDOUT
(60).

To comment further I’d need to know more about your problem. First things first, have you customised the timeouts on your request? Or on the NSURLSession in which you run that request?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
0
LanYueYuGeXing OP
Oct ’17

Thank You for the reply.


My Session setting is like this:

-(NSURLSession *)urlSession{
   if(_urlSession == nil){
       NSURLSessionConfiguration *defaultConfig = [NSURLSessionConfiguration defaultSessionConfiguration];
       defaultConfig.requestCachePolicy = NSURLRequestReloadIgnoringCacheData;
       defaultConfig.timeoutIntervalForRequest = 10;
       defaultConfig.timeoutIntervalForResource = 10;
       _urlSession = [NSURLSession sessionWithConfiguration:defaultConfig delegate:self delegateQueue:[NSOperationQueue mainQueue]];
   }

   return _urlSession;
}

This is not an ordinary timeout. Because the server doesn't receive the request at all.


I used wireshark captured the network traffic. found that after 90s, the client receive a TCP-RST packet. but the clinet doesn't response that. Then next request will send data on a server-closed TCP channel, that cause the error.


I've also found that if we leave the client more than 200s, the client will send TCP FIN packet to server, but becasue server has already close the connection, these packets are all failed


So, only the idle time is between 90s-200s, the next request will failed.


Further more, if I use URLConnection in stead of URLSession, no error will happen. The wireshark shows that URLConnection closes the connection initiatively after the request finished


iOS 8 doesn’t have this problem, does it related with HTTP/2.0?


Thank you very much!

Wang Wei

0
DTS Engineer OP
Apple
Oct ’17 
defaultConfig.timeoutIntervalForRequest = 10;
defaultConfig.timeoutIntervalForResource = 10;

Yikes, those are really short timeouts. If you leave these at the default value, what do you see?

found that after 90s, the client receive a TCP-RST packet. but the clinet doesn't response that.

Right. TCP implementations are not supposed to respond to RST packets.

does it related with HTTP/2.0?

I don’t know. Does your server support HTTP/2.0? That’s the first thing to nail down here because it seems likely that this problem is related to persistent connection management, and that management is completely different on HTTP/1.1 vs 2.0.

You can determine the protocol used for a request from the request’s task metrics (

NSURLSessionTaskMetrics
).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
0
LanYueYuGeXing OP
Oct ’17

"Yikes, those are really short timeouts. If you leave these at the default value, what do you see?"

the same result.

"You can determine the protocol used for a request from the request’s task metrics (

NSURLSessionTaskMetrics
)."

The request is use HTTP/2.0

"it seems likely that this problem is related to persistent connection management, and that management is completely different on HTTP/1.1 vs 2.0."

I think you are right, when use HTTP/2.0 the server close the connection without FIN packet, and in the URLConnection case, the client send FIN initially before the server timetout.

Maybe the server's TCP complile option cause this? But I that is out of my control.

Can I appoint the URLSession to use HTTP/1.1? or I will use URLConnection for work around.

Thank You!

Wang Wei

0
DTS Engineer OP
Apple
Oct ’17

It seems like there are plenty of bugs to go around here:

  • The server should be sending a FIN when it closes the connection.

  • iOS should do better in this situation. Specifically, iOS knows whether the transport error occurred before or after it started sending the request, so it could always retry in the former case and perhaps retry (see below) in the latter.

If you have the ability to log a bug against the server, please do so. Also please file a bug against iOS. It would help if that included:

Please post your bug number, just for the record.

Can I appoint the URLSession to use HTTP/1.1?

No. Which in and of itself is somewhat annoying. Feel free to file an enhancement request for an API to control that.

or I will use URLConnection for work around.

It seems like you’d be better sticking with 

NSURLSession
and retrying the request when you hit this failure.

IMPORTANT Retry is always safe if the request is idempotent but, if not, you’ll need app-specific logic to determine whether to retry or not. See QA1941 Handling “The network connection was lost” Errors for more background on this.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
0
LanYueYuGeXing OP
Oct ’17

I've already file a bug on the bug reporter , the bug No. is: 35066694 (https://bugreport.apple.com/web/?problemID=35066694)


And Thank you for the help again!

Wang Wei

0
DTS Engineer OP
Apple
Oct ’17

I've already file a bug on the bug reporter , the bug No. is: 35066694

Thanks!

Looking at the bug it seems you attached a screen shot of the packet. It’d be much more useful to attach the packet trace itself.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
0
LanYueYuGeXing OP
Oct ’17

the packet trace is added. with the filter condition.

0
TIC Read Status 1:60
First post date Last post date
 
 
Q