in general connection costs are low in bandwidth and low in cpu but high in
latency.. so neither end really minds if we make too many. perhaps the
constant 6 is wrong, but I think any adjustment should be based on data
unless there is a firm problem beig reacted to.

determining h2 does not require http, but it does require tls to be
complete.. this info is cached.

On Mon, Aug 7, 2017 at 10:35 PM, Jason Duell <> wrote:

> So right now we'll launch a new speculative TCP connection (up to 6) for
> each call to the speculative connect API:
> (For HTTP/2,  presumably they get merged into one socket once we figure
> out we're doing H/2, but we won't know that till we actually issue an HTTP
> request IIUC).
> 1) Are we happy with this as the default behavior?   I'm not sure we want
> to open this many speculative sockets to the same host.
> 2) In this bug we're talking about possibly calling the speculative API
> multiple times for the same logical channel (once when the user gets close
> to a link with the mouse, once when they click down on it, etc, and
> possibly also in some central location(s) in the parent before we send off
> a URIload notice to the child):
> I'm thinking we should add a "no-dupe" version of speculative connect for
> this behavior (i.e. it wouldn't start a new speculative connection if
> there's one to that origin already).   Any other ideas?
> 3) For the case where they want to call the speculative API in the parent
> when we actually know 100% that we'll be navigating there (i.e the only
> reason for the call is to launch the socket immediately without having to
> wait for the parent to notify the child about the load), would we want to
> do the same thing we do for regular channels (open 2 sockets in staggered
> succession)?
> Jason
> --
> You received this message because you are subscribed to the Google Groups
> "Necko" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> To post to this group, send email to
> To view this discussion on the web visit
> <>
> .
dev-tech-network mailing list

Reply via email to