[net-dev][cronet] Set http timeout with chromium net stack

[baid...@gmail.com]

Hi

i am using cronet's httpurlconnection, and find that CronetHttpURLConnection does not implement the function 'setConnectTimeout()'. Does anyone know how could i implement it? or is any function like setTimeout in class UrlRequest of chromium net stack or in some classes else?

Thanks for your help

[Matt Menke]

We've been discussing adding such an option.  The problem is that it would force us into not tuning the network stack's timeouts based on network conditions or previously observed behavior (Neither of which we currently do, admittedly), and we don't really have one notion of a connection timeout.  Think of SSL negotiation, proxies, happy eyeballs, falling back to other IP addresses when a DNS name resolves to more than one address, multi-round AUTH, starting backup connections if the first one is taking too long, QUIC, etc.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/e4a20285-f767-4ddf-828e-421a3b9b08a0%40chromium.org.

[Misha Efimov]

Would it make sense to implement on top of Async API? 

Set a timer, and if request status has not reached 'sending request', report a connection timeout failure?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvofxY8ymj8a5A-Jm-XeuiTjC%3DO3q3uq4EoBbtQtFO7bTQ%40mail.gmail.com.

[Matt Menke]

Worth noting anything monitoring request status has to rely on an API based on pulling data from net/, which may add a fair bit of extra overhead.  Also, a number of other problems:

* QUIC:  With 0-RTT connection setup, we skip that phase.

* TCP fast open:  Same issue, unless we're using SSL or certain proxy types.

* Retries:  We use a stale socket, it times out, we then reconnect using a fresh one.  We'll see sending a request, and then moving backwards to an earlier step.  Suppose we can handle this case, if we just notice when we move to a step before sending request.

* Redirects:  If, for instance, the pull API never sees that we sent a request and got a redirect, and then we need to reconnect for the new request, we could be in trouble.

[Matt Menke]

Also, timers for the pull based API presumably keep CPUs awake more often, which could have not insignificant power implications on Android.

Not saying we clearly don't want to introduce such an API, but we should definitely think whether the downsides are worth it.

[will liu]

How is it going now ? 

Indeed,we don't really have one notion of a connection timeout,but we may have one about  RTT timeout now,such as tcp handshake time and response time , like the NetworkQualityEstimator provided.

Suppose we use an stale connection ( unused idle probably )to send request unfortunately , and no any response return from the server leads the TCP stack  just retry again and again.

so , the timeout option is in need so that we can stop a request beyond out expectation.

在 2015年9月9日星期三 UTC+8下午1:12:28，Matt Menke写道：