CloudServices/SimplePushServer

From MozillaWiki
Jump to navigation Jump to search

SimplePush Server

Overview

Provide a service to allow Third Party Application servers to notify their Web Apps that an event has occurred and action may be required, without requiring a web page to be constantly present and connected to the Third Party Application Server

Project Contacts

Principal Point of Contact - Doug Turner dougt@mozilla

IRC - #channel

Group Email - TBD

Goals

Provide a scalable, fast server for the SimplePush protocol as defined by https://wiki.mozilla.org/WebAPI/SimplePush.

In brief, SimplePush is a near dataless method to remotely wake a client application so that it can call "home" and determine what actions are needed. It solves the power and wasted bandwidth concerns of having dozens of applications constantly needing to be connected back with no action required.

This will provide endpoints for both websocket clients and PUTs from third party servers. SimplePush

Use Cases

How will this be used?

Definitions

Requirements

  • APP requests an ENDPOINT from the PUSH CLIENT and shall register two callback functions, one for receipt of the ENDPOINT, and a second for handling of a VERSION EVENT
  • If not already present, PUSH CLIENT shall generate a unique UUID4 Identifier for the UserAgent (UAID)
  • PUSH CLIENT shall generate a unique UUID4 Identifier for the APP (APPID)
  • PUSH CLIENT shall send UAID, APPID and any additional information required for proprietary KICK to the PUSH SERVER
  • PUSH SERVER shall create an ENDPOINT for the UAID and APPID and return it to the PUSH CLIENT.
  • If a KICK driver is present, PUSH SERVER shall relay appropriate PUSH CLIENT provided information to the KICK driver.
  • PUSH CLIENT tenders the ENDPOINT to APP via callback.
  • APP sends ENDPOINT to the APP SERVER
  • On VERSION EVENT, APP SERVER PUTs version value to ENDPOINT
  • If a PUSH CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS.
  • If a PUSH CLIENT is NOT currently connected, an optional, proprietary KICK driver may be called to wake devices associated with the corresponding ENDPOINT UAID.
  • If a PUSH SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage.
  • PUSH CLIENT connects to the PUSH SERVER and shall identify a list of one or more UAIDs it is responsible for.
  • If there are VERSION EVENTS pending for requested UAIDs, PUSH SERVER sends an UPDATE packet (For this template, italicized names would be replaced by actual values):
{ UAID: {
   {APPID: VERSION}, 
   ... },
  ... }
  • If no VERSION EVENTS are pending for the requested UAIDs, PUSH SERVER may return a status indicating no data available (for REST implementations) or simply not return content (for WebSocket)
  • During the transmission of the UPDATE, a PUSH SERVER may wish to return a 503 (Service Unavailable) error to APP SERVERS for any VERSION EVENT associated with an in progress UAID, so as to prevent potential race conditions.
  • On receipt of UPDATE, PUSH CLIENT shall return an ACK to the PUSH SERVER.
  • The ACK shall contain a list of UAIDs for which all APPIDs have been properly received.
  • The PUSH SERVER shall then clear APPID version information from short term storage, and re-allow version updates for those UAIDs if currently blocked.
  • The PUSH CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback, and passing the VERSION

NOTE: a PUSH RELAY may be created by combining the polling aspects of the PUSH CLIENT with the data management and KICK driver of the PUSH SERVER. This would allow a VERSION EVENT system to enter protected networks or use restricted means to communicate to USER AGENTs. It is important to note that once a PUSH SERVER has received an ACK for a given UAID, the PUSH SERVER is under no obligation to retain that data, and proper relay of the VERSION EVENT is the PUSH RELAY's problem.

Get Involved

Call to action for folks who want to help.

Design

Points of Contact

Server Engineer - "trink" trink@mozilla Server Engineer - JR Conlin jrconlin@mozilla Client Engineer -

API Reference/Documentation

Data Schema

How will data be stored

API

How to call the data

method URI

description

Arguments argument descriptions
Returns: returned contents

Platform Requirements

What are the things this needs (OS, language, databases, etc.)?

Libraries Required

List of external project dependencies. (Stuff that's not pulled in via the installation script)

Code Repository

Links to the published code bases

Release Schedule

Predicted code delivery dates

QA

Points of Contact

Engineer - Name contact@info

Test Framework

Security and Privacy

Fill out the security & privacy bug template: https://bugzilla.mozilla.org/form.moz-project-review (https://wiki.mozilla.org/Websites/Kick-Off_Form)

Points of Contact

Questionnaire Answers

1.1 Goal of Feature

2. Potential Threat Vectors and Mitigation Points

Review Status

Bugzilla Tracking # - see https://wiki.mozilla.org/Security/Reviews

Issues and Resolutions

Operations

Points of Contact

Deployment Architecture

Bugzilla Tracking # -

Escalation Paths

Lifespan Support Plans

Logging and Metrics

Points of Contact

Tracking Element Definitions

Data Retention Plans

Dashboard URL

Customer Support

Points of Contact

Sumo Tags

Review Meeting