On 2/25/2016 14:41, Daniel Stenberg wrote:
> On Thu, 25 Feb 2016, Honza Bambas wrote:
>> First, how are you detecting slow connections? Just by not receiving
>> If so, that is a wrong approach and always was.
> I'm not detecting slow connections at all. We attempt to detect
> stalled HTTP/1
> connections where absolutely nothing gets transferred.
OK, and how do you recognize it? From the problem you described it
seemed like you are checking on intervals between chunks you receive in
socket transport or connection or transaction. That is the "not
receiving data" approach I refer to. That is the approach that never
> It can happen when you
> move your browser between networks. Like when changing between wifi
>> You have out of bounds ways to detect this - TCP keep alive. I don't
>> remember if that has been put off the table as uncontrollable on all
>> platforms or too faulty. If not, setting the TCP keep-alive timeout
>> _during the time you are receiving a response_ to something
>> reasonable (your 5 seconds) will do the job for you very nicely.
> Adaptive keep-alive! I like that. Just a tad bit worried it'll
> introduce other problems as it'll then make _all_ transfers get that
> keepalive thing going at a fairly high frequency
It doesn't need to be a super high frequency. You will only enable it
between request sending and last response bit receive (complete). You
can also engage it on open connections only after a network change has
been detected and only for a short period of time, but I would like to
have such a mechanism engaged all the time. Connections may drop not
just because your adapter configuration changes.
> and not only the rare ones where we get a network change. For example
> the mobile use cases tend to not like keepalive. But maybe I'm just
> overly cautious.
On idle connection I would return to a normal t/o logic we have (I think
we don't use TCP keep-alive at all on idle conns)
>> And I also think that 5 seconds is a too small interval. At least 10
>> do better IMO.
> It was mostly just a pick to get something that would still feel good
> enough for truly stalled connections and yet have a fairly low risk of
> actually interferring with a slow-to-respond server.
> Anything in particular that makes you say that 10 is better? Why not 8
> or 12?
Yeah :) that's it! nobody knows what this should be...
>> Other way is to rate the _response_ and probably also each
>> _connection_. You can measure how fast they are receiving and adjust
>> your timeout according it. Still not a perfect solution and also not
>> simple and also stateful.
>> From my experience, the slowest responses take a long while for the
>> server to
> start responding and in those cases we'd have 0 bytes transfered for a
> while and thus nothing to adapt the timeout to at that point.
Yep, imperfect solution, right. TCP k-a would tho catch this.