[NetInfo] feedback which I prepared for PhoneGap

I was asked to discover why people believe certain things should be present in the DAP NetInfo API.

Roughly, to develop "applications" suitable for an App Store, one has a couple of requirements. The store requires Applications to work *well* when there's no network [N1]. If the application is working on a mobile device with a mobile network, then the carrier is likely to terminate idle sockets. The termination time apparently varies by network generation (but also is likely to vary from carrier to carrier) [N2]. There's also a general need to be able to select the optimal bandwidth for a stream (e.g. video) possibly favoring a higher quality version -- but only if it works [N3].

So, you need:
N1. A way to check for online.
N2. A way to know the socket timeout (because if you know the timeout you can send NOPs to prevent it).
N3. A way to know your bandwidth so you can select appropriate bit-weights for streaming.

I'm writing this email using a BlackBerry PlayBook, because I'm outside, sitting down, and want to use a bigger keyboard than the one on my BlackBerry Torch.

A year ago, I'd probably have used my MacBook Pro. While both devices are WiFi capable, the three open networks nearby are unfamiliar, so I'm forced to use another means to get online. With the MacBook, I'd use one of the following techniques to get online:
A. USB Ethernet to a Nokia n900 doing NAT for its Cellular connection.
B. USB modem (same n900)
C. Bluetooth DUN (same n900)
D. WiFi to someone's MiFi hotspot (e.g. a ClearWire 4G spot)
E. WiFi to someone's Android which is acting as a hotspot and graciously sharing its Cellular connection.

Since I'm using my PlayBook, I'm using BlackBerry Bridge. With it, network traffic is sent using Bluetooth to my Torch, which could then send it over:
F. Cellular (Bridged-Cellular)
G. WiFi (Bridged-WiFi) - this useful because my torch has vpn access, so even though one might generally expect Bridging to WiFi to be pointless from a WiFi enabled device, it in fact is quote valuable.

I'll have to do some research to find out whether the bridge clients know anything about network topography on the other side of he bridge (i.e. Whether we can distinguish F from G).

It should be clear that we can't distinguish D from E, and I believe there's no way to discover details for a number of the other topographies (programmatically).

-- I stopped to watch the movie -- sorry for the delay

It seems to me that the right approach for an application when starting is:
S1. Trigger an async XMLHttpRequest to the server it's using
S2. Load its local (for offline support) content
S3. If it gets a response from S1, it's online and it should transition to online by loading content / whatever from the network 

Collectively, S1-S3 address N1.

S4. If you need to maintain a socket (XMLHttpRequest [2] or WebSocket [3]) for bidirectional communication to your server, create the connection and get the current time.
S5. If you have established a heartbeat interval in S7, then at that interval from your last send/receive send a heartbeat (this counts as data in S6).
S6. Each time you send or receive data over the wire, get the current time and subtract the previous time from it, store this delta in a list.
S7. When your socket dies, get the current time and get its delta to the previous sent/received time. Compare that delta with elements in the list built in S6. If the time is shorter than the last couple, then it's either a flaky network or a different network. If it's longer then you might want to pick a time between your longest success delta and your recent failure and use it for a keepalive.

Collectively, S4-S7 address N2.

If you are trying to stream content, you should be able to determine if your stream is underrunning or if your buffer is filling too fast. The following assumes you are using a <video> [4] object (and that for some reason you refuse to provide multiple <source> [5] tags which would let the browser do this work for you).
S8. Register for onemptied, onstalled, onwaiting - onstalled [6] will tell you if your pipe is too small for the stream. If you stall repeatedly within some window, then you should lower your bandwidth requirements because the current level is overwhelming your pipe.
S9. Register a timer which lets you sample .mozDroppedFrames [7] (and other similar attributes from other vendors, this area isn't yet standardized, so you get to contribute to show how it'd be useful/used), if the number is "too high" during an interval and you haven't stalled recently then you should lower your bandwidth requirements because the current level is overwhelming your sink.
S10. On that timer, if neither S8 nor S9 have triggered a downgrade in a while then you can try adding an extra stream whose data cost would be a bit beyond the delta to your next better stream.
S11. If after some time S10 hasn't triggered an S8 or S9 and. Its data is arriving on time, then kill the S10 stream and upgrade the main stream to the higher bandwidth source.

Collectively S8-S11 address N3, or you could provide multiple <source>s and let the browser do this work for you for free.... Note that while this section was described w.r.t. <video>, it should apply to any system which involves streaming as you should always be able to decide that the system isn't responding (if your setInterval isn't firing as regularly as you want -- by a significant amount) or if you think it can do more (because you can always try to do more work and see if the system falls apart).

The above could certainly be rolled into a library for testing and iterating, and it'd be great if someone did that. I think it's pretty clear that the above does not map well to a request to know if a network is `2G` or `3G`. It's unclear if one even needs onLine [1] (the heuristics for it actually turned out to be pretty bad, whereas using an XMLHttpRequest will just work).

[1] http://developer.mozilla.org/en/DOM/window.navigator.onLine
[2] http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
[3] http://dev.w3.org/html5/websockets/
[4] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element
[5] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-source-element
[6] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#event-media-stalled
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=580531

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 16 August 2011 23:50:46 UTC