11436 SSO

Piggy-Backed Mobile Network Transmissions & the Apigee Mobile Analytics SDK

pdardeau
Jan 24, 2013

In my last blog post, Optimizing for Mobile? Bounded, Piggy-Backed Mobile Network Transmissions, I talked about a way to reduce battery consumption and optimize apps for mobile.

The current implementation of the Apigee Mobile Analytics SDK (Android and iOS) follows a simplistic timed interval (60 seconds by default) for upload of secondary traffic (device metrics). This guarantees that the radio will be in the high state (turned on if it were off) at least once per minute. We will be revving our SDK to build in a bounded, piggy-backed strategy for secondary traffic to support the arguments in the previous blog post.

iOS and Android Networking Interfaces
On iOS, an initial implementation might provide  new category methods on NSURLConnection:


+ (NSURLConnection*) secondaryTrafficConnectionWithRequest:(NSURLRequest *) request
                                      delegate:(id < NSURLConnectionDelegate >) delegate;

+ (NSData *) secondaryTrafficSendSynchronousRequest:(NSURLRequest *) request
                      returningResponse:(NSURLResponse **)response
                                  error:(NSError **)error;

+ (void) secondaryTrafficSendAsynchronousRequest:(NSURLRequest *)request
                               queue:(NSOperationQueue *)queue
                   completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler;

- (id) initSecondaryTrafficConnectionWithRequest:(NSURLRequest *)request
                            delegate:(id < NSURLConnectionDelegate >)delegate;

- (id) initSecondaryConnectionWithRequest:(NSURLRequest *)request
                            delegate:(id < NSURLConnectionDelegate >) delegate
                    startImmediately:(BOOL) startImmediately;

On Android, an initial implementation might provide specialized classes and subclasses:


public class SecondaryTrafficHttpURLConnection extends java.net.HttpURLConnection
public class SecondaryTrafficHttpsURLConnection extends javax.net.ssl.HttpsURLConnection

public class SecondaryTrafficHttpClient implements org.apache.http.client.HttpClient

Implementation Approach
Here are some preliminary thoughts on how we might implement this in our Mobile Analytics SDK.

At the beginning of the app session, and again after every upload of secondary traffic:

Establish a Max Inter-Transmission Time timer so that we're notified when this amount of time has passed.

Hold onto the current time so that we can check for our minimum bound condition.

Establish a 'unit of work' timer for every primary network transmission. This timer is set up to detect when the primary traffic 'unit of work' has completed, but radio still in high state. The timer would likely be set to fire after 4 or 4.5 seconds (before the radio steps down from high (DCH) to intermediate (FACH) state). When a new primary network transmission occurs, if there is an outstanding 'unit of work' timer, just cancel it (a newer timer will take its place).

When a 'unit of work' inactivity timer is fired:

IF Min Inter-Transmission Time has elapsed since our last secondary transmission

THEN

  1. cancel outstanding Max Inter-Transmission Time timer
  2. upload secondary traffic
  3. hold onto current system time
  4. create new Max Inter-Transmission Time timer

ELSE
        do nothing (otherwise we'd be violating our minimum bound configuration)

When a Max Inter-Transmission Time timer is fired:

  1. cancel any outstanding 'unit of work' inactivity timer (if present)
  2. upload secondary traffic
  3. hold onto current system time
  4. create new Max Inter-Transmission Time timer

Apigee Mobile Analytics SDK -- Eating Our Own Dog Food
The current implementation of the SDK follows a simplistic timed interval (60 seconds by default) for upload of secondary traffic (device metrics). This guarantees that the radio will be in the high state (turned on if it were off)
at least once per minute.

Based on the analysis presented in Optimizing for Mobile? Bounded, Piggy-Backed Mobile Network Transmissions, we are planning to implement a bounded, piggy-backed strategy for secondary traffic. We will likely use the following default values for the bounding parameters:

Min Inter-Transmission Time = 20 seconds (guarantee that we won't be uploading metrics any more often than this value)

Max Inter-Transmission Time = 3 minutes (guarantee that the device will send metrics at least this often)

We'd love to get your perspective - whether you agree, disagree, have other ideas, we welcome your feedback at mobile@apigee.com.

API Management Decision-Making Kit

Next Steps

 
 

Resources Gallery

News