the remedies are backwards looking (flush caches, close connections etc).. so the phrasing about the hash was probably too lazy, but perhaps the basic idea has merit?
On Thu, Feb 25, 2016 at 9:01 AM, Daniel Stenberg <[email protected]> wrote: > On Thu, 25 Feb 2016, Patrick McManus wrote: > > The discussion here should be about the signal (that the network has >> changed) - if the remedy needs to be tweaked (which I'm not convinced of) >> we can do that separately. Remember that there are quite a few things that >> get done as part of the remedy not even mentioned here and the real issue >> here is that the signal is too noisy. So let's talk about the signal. >> >> I don't think we want to just ignore teredo - a tunnel coming and going >> is relevant to the general problem at hand, but it appears the tunnel isn't >> relevant to the use case of the reporter. >> >> Here's a basic question - is the address of the tunnel ever used by necko >> in the log? Perhaps we could only hash interfaces with addresses that have >> seen use.. >> > > Very good point. The multiple triggers will still be bad even if the > HTTP/1 connections would surive. > > The log I have doesn't reveal that detail, it was limited to detecting > what the network changes were. Since the user didn't even know there was a > network change, my guess is that it wasn't actually used. Of course I can > ask about it, or get more logs. > > But then, just because it wasn't used (I'm not even sure how we should > decide if the interface was used) the previous time the interface was > present I don't think we can assume that it won't be used this time... > > > -- > > / daniel.haxx.se > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
