5 ms·

Given the "preload any data the user might need in the next 2-5 mins" statement, how do people suggest we handle live streaming of updates (eg commentary on a s

Given the "preload any data the user might need in the next 2-5 mins" statement, how do people suggest we handle live streaming of updates (eg commentary on a sports event)? Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model?

jaytaylor 13y ago
> Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model? This is seems incorrect - as I understand it, a websocket holds open a TCP connection indefinitely, which would require the radio to stay in its active state as long as the websocket remained open. See also: http://stackoverflow.com/questions/4456407/iphone-keep-websocket-open-in-background http://stackoverflow.com/questions/4456407/iphone-keep-webso...
- kevinbowman 13y ago
  That's true, although I guess it's mostly listening as opposed to sending, which is possibly better? Although I realise there's probably some kind of "are you still there?" message from the cell tower.
- ryanpetrich 13y ago
  I can't speak for websockets, but holding a TCP connection open indefinitely does not require that the radio stay in its active state. On iOS, setting the kCFStreamNetworkServiceTypeVoIP property on the connection allows the radio to return to the idle state and reawake when it receives data on the socket. Android may have similar APIs.
  - sliverstorm 13y ago
    Wouldn't the radio have to wake on a timer to scan? How else will you notice there is data waiting on the other side of the connection?
    - ryanpetrich 13y ago
      The radio is in a low power idle state, the same state used to wait for incoming phone calls and text messages.
- mikeash 13y ago
  I think the radios are down at the IP level and have no concept of a TCP connection, so an open but idle connection won't keep the radio from shutting off. For example, Apple recommends that VoIP apps on iPhones keep a TCP socket permanently open and use it to receive notifications of new calls and similar: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/AdvancedAppTricks/AdvancedAppTricks.html#//apple_ref/doc/uid/TP40007072-CH7-SW12 https://developer.apple.com/library/ios/documentation/iphone...
  - tjohns 13y ago
    This is outside my area of expertise, but I've heard that there's a keepalive timeout for open sockets set by the cell carriers. (Again, don't know the details.) So, there is a small cost to keep a TCP connection open, in order to avoid this timeout. Also, as I mentioned in my previous comment: Even if keeping the socket open is free, every time you send a packet there's a cost -- both for the actual data transmission, as well as a medium-power state the radio enters for a bit before really going to sleep. And given the number of apps that use background data, background traffic on a phone can get quite chatty. This is why it's important to synchronize background activity across apps. If you implement your own push channel, there's no way for the OS to do any sort of synchronization.
tjohns 13y ago
GCM is the recommended solution for anything that's trying to "push" data to Android: http://developer.android.com/google/gcm/index.html http://developer.android.com/google/gcm/index.html We (Android) usually don't recommend developers try to implement push themselves. Using GCM allows the Android servers to schedule and collate data transmissions, so push messages from different apps get sent as part of the same transmission. Anything you roll yourself won't be able to do this.
- kevinbowman 13y ago
  What about for a webapp, even an offline one? Is there a hook into GCM from Javascript or something like that?
  - tjohns 13y ago
    I suppose you could use the Java-to-JS bridge, if you're using WebView inside a native app. However, there's not really any "mobile-friendly" push solution available as part of HTML5 right now. I wish there was. There's "GCM for Chrome" (http://developer.chrome.com/apps/cloudMessaging.html http://developer.chrome.com/apps/cloudMessaging.html), but that's both Chrome-only and only available on the desktop.

jaytaylor 13y ago

> Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model? This is seems incorrect - as I understand it, a websocket holds open a TCP connection indefinitely, which would require the radio to stay in its active state as long as the websocket remained open. See also: http://stackoverflow.com/questions/4456407/iphone-keep-websocket-open-in-background http://stackoverflow.com/questions/4456407/iphone-keep-webso...

kevinbowman 13y ago
That's true, although I guess it's mostly listening as opposed to sending, which is possibly better? Although I realise there's probably some kind of "are you still there?" message from the cell tower.
ryanpetrich 13y ago
I can't speak for websockets, but holding a TCP connection open indefinitely does not require that the radio stay in its active state. On iOS, setting the kCFStreamNetworkServiceTypeVoIP property on the connection allows the radio to return to the idle state and reawake when it receives data on the socket. Android may have similar APIs.
- sliverstorm 13y ago
  Wouldn't the radio have to wake on a timer to scan? How else will you notice there is data waiting on the other side of the connection?
  - ryanpetrich 13y ago
    The radio is in a low power idle state, the same state used to wait for incoming phone calls and text messages.
mikeash 13y ago
I think the radios are down at the IP level and have no concept of a TCP connection, so an open but idle connection won't keep the radio from shutting off. For example, Apple recommends that VoIP apps on iPhones keep a TCP socket permanently open and use it to receive notifications of new calls and similar: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/AdvancedAppTricks/AdvancedAppTricks.html#//apple_ref/doc/uid/TP40007072-CH7-SW12 https://developer.apple.com/library/ios/documentation/iphone...
- tjohns 13y ago
  This is outside my area of expertise, but I've heard that there's a keepalive timeout for open sockets set by the cell carriers. (Again, don't know the details.) So, there is a small cost to keep a TCP connection open, in order to avoid this timeout. Also, as I mentioned in my previous comment: Even if keeping the socket open is free, every time you send a packet there's a cost -- both for the actual data transmission, as well as a medium-power state the radio enters for a bit before really going to sleep. And given the number of apps that use background data, background traffic on a phone can get quite chatty. This is why it's important to synchronize background activity across apps. If you implement your own push channel, there's no way for the OS to do any sort of synchronization.

tjohns 13y ago

GCM is the recommended solution for anything that's trying to "push" data to Android: http://developer.android.com/google/gcm/index.html http://developer.android.com/google/gcm/index.html We (Android) usually don't recommend developers try to implement push themselves. Using GCM allows the Android servers to schedule and collate data transmissions, so push messages from different apps get sent as part of the same transmission. Anything you roll yourself won't be able to do this.

kevinbowman 13y ago
What about for a webapp, even an offline one? Is there a hook into GCM from Javascript or something like that?
- tjohns 13y ago
  I suppose you could use the Java-to-JS bridge, if you're using WebView inside a native app. However, there's not really any "mobile-friendly" push solution available as part of HTML5 right now. I wish there was. There's "GCM for Chrome" (http://developer.chrome.com/apps/cloudMessaging.html http://developer.chrome.com/apps/cloudMessaging.html), but that's both Chrome-only and only available on the desktop.