locked
Universal App HttpClient does not close request on timeout

    Question

  • I'm running into an issue where I have a HttpClient.SendAsync() times out and the request is staying open.

    I have tried using:

    * HttpClient.Timeout

    * CancellationTokenSource.CancelAfter() & CancellationTokenSource.Cancel in TaskCanceledException (triggered by Timeout)

    * HttpClient.CancelPendingRequests in the TaskCanceledException (triggered by timeouts).

     I'm using "Using" for the HttpClient and HttpRequestMessage.

    What am I missing to get this timed out request to be closed?

    Thanks,

    Mark


    mark

    Tuesday, June 10, 2014 6:45 PM

Answers

  • There is no property available on the Windows.Web.Http.HttpClient class that lets you set the underlying Socket's write buffer size. If the server side's TCP Window is getting full, TCP will backoff and keep sending the zero window packets until the server side can drain out its socket/ TCP buffer and advertise a larger window size at which point the send will resume. Why is your kiosk resetting the underlying TCP connection? If you cannot change the server implementation, maybe you can use StreamSocket class directly and stream the data as per what your server accepts

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Thursday, June 26, 2014 8:36 PM
    Moderator

All replies

  • Can you share your repro code so that we can understand your repro and try to mimic the issue here...Which platform are you seeing this issue on? Windows 8.1 or Windows Phone 8.1?

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, June 10, 2014 11:06 PM
    Moderator
  • It's really hard to reproduce this issue, unless you have my client's kiosk which it's connecting to. One of my MSFT connects told me to take a look at wireshark traffic. From that I can see that the client is putting a lot more data into the TCP window than what the kiosk can take out. If there is small amount of data, couple of MB, that goes through it can retransmit the loss TCP segments. But when more data gets pushed through fast, like 10+MB, then I start seeing TCP resets occurring and the data gets lost.

    What funny is I'm using the same code for both platforms, phone and windows store. Phone works just fine; it the windows store version is having all of the issues. I'm not sure if it's due to faster processing power of the PCs or if the httpclient implementation has different settings between the 2 platforms. Maybe the phone version has small tcp packet sizes being pushed, so the kiosk is able to keep up with it; and the pc packet sizes are larger, so the kiosk isn't able to keep up.

    Is there a way to change the tcp packet size with the httpclient? Might be something I can try to test.

    Thanks,

    Mark


    mark

    Thursday, June 12, 2014 1:19 PM
  • There is no property available on the Windows.Web.Http.HttpClient class that lets you set the underlying Socket's write buffer size. If the server side's TCP Window is getting full, TCP will backoff and keep sending the zero window packets until the server side can drain out its socket/ TCP buffer and advertise a larger window size at which point the send will resume. Why is your kiosk resetting the underlying TCP connection? If you cannot change the server implementation, maybe you can use StreamSocket class directly and stream the data as per what your server accepts

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Thursday, June 26, 2014 8:36 PM
    Moderator