CloudServices/Roadmaps/SimplePush-Server: Difference between revisions

← Older edit

CloudServices/Roadmaps/SimplePush-Server (view source)

Revision as of 19:54, 19 November 2013

1,995 bytes added , 19 November 2013

m

Telliott moved page Services/Roadmaps/SimplePush-Server to CloudServices/Roadmaps/SimplePush-Server

Telliott

canmove, Confirmed users

1,173

edits

@@ Line 2: / Line 2: @@
 ==Overview==
 A server for the SimplePush Notification alert system. See https://wiki.mozilla.org/WebAPI/SimplePush for a brief introduction.
+The slightly more friendly [https://docs.google.com/presentation/d/1diBRvayCwPhs6KVjIIdClmpXZO_-lAgDAX9v6OKHFjM/edit#slide=id.p slide deck] is also available.
 ==Project Contacts==
 * ''Principal Point of Contact'' - Doug Turner <i>dougt@mozilla</i>
 * ''IRC'' - #push
-* ''Group Email'' - TBD
+* ''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 [http://research.google.com/pubs/pub37474.html 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.
@@ Line 14: / Line 20: @@
 ==Use Cases==
-<i>How will this be used?</i>
+See use cases specified under:
+https://wiki.mozilla.org/WebAPI/SimplePush#Use_Cases
-https://wiki.mozilla.org/WebAPI/SimplePush
-http://www.michaelpiatek.com/papers/thialfi-sosp11.pdf
+<!-- http://www.michaelpiatek.com/papers/thialfi-sosp11.pdf -->
 ==Tracking Bug==
@@ Line 51: / Line 57: @@
 ==Libraries Required==
-The 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 [https://github.com/mozilla-services/pushgo 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 mod_test module testing unit uses python 2.7 and requires VirtualEnv to be properly installed.
+The [https://github.com/mozilla-services/simplepush_test 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.
@@ Line 65: / Line 71: @@
 =QA=
 ==Points of Contact==
-Engineer - <i>Tony Chung</i> <i>tchung@mozilla.com</i>
+Services QA
+Engineer - <i>Edwin Wong</i> <i>edwong@mozilla.com</i>
 ==Test Framework==
@@ Line 83: / Line 90: @@
 =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==
-Doug Turner <dougt@mozilla.com>
+JR Conlin <jrconlin@mozilla.com>
-==Questionnaire Answers==
-===1.1 Goal of Feature ===
-To provide an internet scale, easy to use, notification system.
-===2. Potential Threat Vectors and Mitigation Points===
 ==Review Status==
 ''Bugzilla Tracking #'' -
@@ Line 103: / Line 107: @@
 Tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=853214
 ==Points of Contact==
+bwong@
+oremj@
 ==Deployment Architecture==
-''Bugzilla Tracking # '' -
+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==