CloudServices/Roadmaps/SimplePush-Server
Contents
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
- Principal Point of Contact - Doug Turner dougt@mozilla
- IRC - #push
- Group Email - https://mail.mozilla.org/listinfo/dev-simplepush
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
