On Thursday, May 24, 2012 8:09:57 AM UTC-5, [email protected] wrote: > On Wednesday, May 23, 2012 3:18:52 PM UTC-4, (unknown) wrote: > > I know it's not supposed to make a difference, but in our unusual case it > > actually does. I won't bore you with the details, > > please do share - I'd like to know the details. That's the only way we can > figure out if we should make such a thing available. It is indeed supposed to > be transparent so we haven't done so at this point.
Sorry, yes, I'm getting ahead of myself. I'm afraid there's a bit of a story here. Docs opens a hanging GET connection per tab, to receive collaborator updates from the server. Users routinely open large numbers of tabs, making maximum per-origin connection limits an issue. I'm not sure what that number is in Firefox right now, but at least traditionally it's been lower than we've been comfortable with. To get around the limit, we open each hanging GET to a different numbered subdomain of docs.google.com. When we first tried this technique in Chrome, it disagreed with their SPDY implementation. When SPDY in Chrome is active, the per-origin connection limit is lifted to a much higher number, the maximum stream count on the SPDY connection. On the other hand, there was a pool of SPDY TCP connections which was much smaller, and which we were consuming one of each time we connected to one of our numbered subdomains. To maximize the chances of their being able to reuse one of these connections, Chrome had each one live for a short time after the last stream on it disconnected. This made it possible to exhaust the pool when large numbers of docs tabs were open, and for it to stay exhausted for a while even after they closed. We found ourselves in a situation where if we used our normal technique on SPDY we had a failure, and if we disabled our tricks and simply connected to docs.google.com, we also had a failure on non-SPDY clients. This made it necessary to detect whether SPDY was actually in play on a given tab. Chrome happened to have such an API, so we used it. I jumped ahead of myself and assumed that I'd have a similar problem on Firefox, although of course being an independent implementation it may have completely different characteristics. I haven't actually tested our solution on Firefox/SPDY yet, so I'm not sure. I'd point out that without such an API or something similar it's hard to work out whether I've conducted a valid test - hopefully the use of SPDY at least shows up in firebug or some other debugging tool? I'd hate to be getting out my packet sniffer :-) Even if there isn't a stability issue here, even if the pool of SPDY tcp connections is large and not a problem, there is still a case for differing behavior when SPDY is active. The use of random subdomains to circumvent connection limits has costs. DNS lookups are needed, and it defeats SPDY's ability to establish multiple http connections over one TCP connection. Even if our existing solution is stable in the presence of SPDY on Firefox I'd slightly prefer to disable it, assuming the presence of SPDY effectively lifts the per-origin connection limit, as it does on Chrome. Sorry for the essay and thanks for listening. I'd appreciate any feedback that occurs to you. Regards, -Dave _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
