ConnectionType for tethering? about netinfo HOT 3 OPEN

As specced, ConnectionType reports the first hop.. which will be either WiFi or Bluetooth or ..., depending on the type of hotspot you're connecting to. ECT, on the other hand, will be determined by the end-to-end performance, so yes CT may say "wifi" while ECT can report "slow-2G".

Does that help?

from netinfo.

Thank you. Imho the spec could be a little clearer about that. There's lots of language about "first hop" for downlinkMax, but I didn't find a single mention of "first hop" for type.

To summarize, this my understanding of which hop each of the attributes relates to:
type -- first hop
effectiveType -- most limiting hop
downlinkMax -- first hop
downlink -- most limiting hop
rtt -- most limiting hop

I'd like to note that for tethered connections, using the first hop for type breaks all web app use cases (4.1, 4.2, 4.3) that are mentioned in the review doc. Imho it would be really great if we could amend the spec to handle tethering gracefully.

For me it would seem easiest to let go of the notion of the first hop and replace it by most limiting hop known to the client. In the absence of tethering indicators that would be the first hop thus no changes there, however when tethering is detected (e.g. via ANDROID_METERED DHCP option) the type could be reported as "cellular". (Though without further knowledge about the cellular link, downlinkMax would have to be reported either as infinity or for the connection technology of the first hop.)

Imho that change would make the spec clearer, because now all five attributes would consistently relate to the most limiting hop. Any thoughts?

from netinfo.

To summarize, this my understanding of which hop each of the attributes relates to:
type -- first hop
effectiveType -- most limiting hop
downlinkMax -- first hop
downlink -- most limiting hop
rtt -- most limiting hop

Yep, and thanks is great feedback.. Agree that we should spell this our more clearly in the spec.

Re, first hop vs most limiting hop: we're veering into discussion in #41 (comment) -- let's take it there, to avoid parallel threads.

from netinfo.