CloudServices/Roadmaps/SimplePush-Server

From MozillaWiki
Jump to: navigation, search

SimplePush - Server

Overview

A server for the SimplePush Notification alert system. See https://wiki.mozilla.org/WebAPI/SimplePush for a brief introduction.

The slightly more friendly slide deck is also available.

Project Contacts

Goals

It's quite easy for remote devices to connect back to a server, but it's difficult for the server to connect back to the remote devices. This is even more true with mobile devices. Maintaining a lot of individual port connections (even if they're just polling) can lead to very short battery lives.

Simplepush attempts to address this by having a single port connection maintained back to a central server. Applications register a callback with SimplePush, which returns a URL that can be passed to the remote server. As interesting things happen, the remote server can check to see if there's a live connection to the App, and if not, can use the URL to wake the remote app.

SimplePush is based off of Thialfi. This system manages version numbers for assigned channels. In short: A client checks to see if it's version matches what's on the push server. If so, do nothing, if not, go fetch from the app server.

This system provides a low cost, scalable, system to manage these version lookups.

Use Cases

See use cases specified under: https://wiki.mozilla.org/WebAPI/SimplePush#Use_Cases


Tracking Bug

https://bugzilla.mozilla.org/show_bug.cgi?id=878178

Get Involved

Call to action for folks who want to help.

Please drop on to irc.mozilla.org #push, or email:dougt@mozilla.com

Design

Points of Contact

Engineer - JR Conlin jrconlin@mozilla

API Reference/Documentation

See API documentation

Platform Requirements

The system has been designed and tested for Linux using both Ubuntu Precise and AWS flavors.

Libraries Required

The pushgo system currently is based on Go. It is strongly recommended at this time to use the latest Go Tip source, or at the very least Go 1.1.

The simplepush_test module testing unit uses python 2.7 and requires VirtualEnv to be properly installed. This module is designed to be a platform agnostic method to test the simplepush server for operations and compliance.

All other dependencies are brought in by the respective installers.

Code Repository

https://github.com/jrconlin/pushgo

Release Schedule

The Code Release schedule has not yet been finalized and is thus "ad hoc"

QA

Points of Contact

Services QA Engineer - Edwin Wong edwong@mozilla.com

Test Framework

A simple module test framework is provided in the ./mod_test directory. This tests the active server by

  • connecting as a websocket,
  • issuing a "hello" as UAID "test",
  • registering a "test1" ChannelID,
  • Sending a PUT request to the returned endpoint URL
  • Monitoring the websocket for an update for the "test1" ChannelID
  • Unregistering the "test1" ChannelID
  • Tearing down the websocket connection

A module test approach was preferred since unit tests would require too much mock work to provide meaningful tests.

This framework should be extended to include negative tests.

Security and Privacy

Refer to https://wiki.mozilla.org/Services/Roadmaps/SimplePush-Server/SecurityReview

Refer to https://wiki.mozilla.org/Services/Roadmaps/SimplePush-Server/SecCodeReview

Points of Contact

JR Conlin <jrconlin@mozilla.com>

Review Status

Bugzilla Tracking # - https://bugzilla.mozilla.org/show_bug.cgi?id=831816

see https://wiki.mozilla.org/Security/Reviews

Issues and Resolutions

Operations

Tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=853214

Points of Contact

bwong@ oremj@

Deployment Architecture

https://bugzilla.mozilla.org/show_bug.cgi?id=853214

Current deployment consists of a bank of servers for socket connections, with an ELB fronted set of machines to handle PUT updates. This was created because the current version of Go requires a surprisingly high amount of CPU in order to process TLS requests. Offloading the TLS termination to ELB with a bank of proxy points provided the highest level of service.

Escalation Paths

Lifespan Support Plans

Logging and Metrics

Currently logging and metrics will be performed via Heka integration.

The Heka endpoint machine has not yet been identified, although an interim machine has been created for internal use.

Points of Contact

TBD: (currently jrconlin@)

Tracking Element Definitions

Since user data is meaningless, most tracking will be operational (length of Websocket connection, number of connections, update rates, etc.)

Data Retention Plans

Logging information will be sent to Heka for aggregation reports. There are no plans for retention of any individual or user identifying logging information.

Dashboard URL

TBD

Customer Support

Points of Contact

Sumo Tags

Review Meeting