canmove, Confirmed users
1,173
edits
CloudServices/Roadmaps/EditionServer: Difference between revisions
CloudServices/Roadmaps/EditionServer (view source)
Revision as of 19:54, 19 November 2013
, 19 November 2013Telliott moved page Services/Roadmaps/EditionServer to CloudServices/Roadmaps/EditionServer
No edit summary |
m (Telliott moved page Services/Roadmaps/EditionServer to CloudServices/Roadmaps/EditionServer) |
||
| (13 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<h1><i> | <span style="color:red">This is a draft document. It is a work in progress.</span> | ||
<h1><i>PlaceHolder Server</i></h1> | |||
==Overview== | ==Overview== | ||
The Placeholder Server provides a SERVICE to allow third-party Application Servers to notify their Web Apps that an event has occurred and action may be required. The nature of this action will be defined by the app receiving the notification. | |||
The Placeholder Server is MINIMALIST. Setting up your own server should be a simple operation*. Because it runs over HTTP/Websockets, endpoints can be controlled by the user. (*offer of simplicity may not apply for connecting to proprietary networks, e.g. cell phones) | |||
The Placeholder Server is HIGH-CAPACITY. Each machine can handle hundreds of thousands of connected accounts and thousands of messages a second. | |||
The Placeholder Server is SCALABLE. Capacity can be increased in near-linear fashion by the addition of more machines. | |||
The Placeholder Server is AGNOSTIC. It does not validate the user or the channel. Any ping sent into the system will be accepted and made available to a client listening on that channel. | |||
The Placeholder Server is BEST EFFORT. It will do what it can to deliver the ping, and will succeed the vast majority of the time. If the ping is currently undeliverable, it will cache it for the next time the client checks in. However, if disaster strikes, it is possible an attention ping will be lost. | |||
The Placeholder Server is TRANSIENT. Pings that have not been delivered after a configurable time (likely 36 hours) will be discarded. | |||
The Placeholder Server is NONLINEAR. The order of pings through a channel is irrelevant and nonsequential. The client can tell that there is something that needs attention by the presence of the ping, not the contents of it. Normally, however, the value in the ping will be different from the previous value, to optimize for duplicate delivery. However, this is handled by the Application Server and is not guaranteed. | |||
The Placeholder Server is NONACCUMULATIVE. If two pings come in for the same channel while the client is disconnected, only one of those pings will eventually be delivered. No guarantee is made as to which it is (see NONLINEAR). | |||
The Placeholder Server is OPAQUE. Only the user will have knowledge of the UAID. The Application Server will be pushing data to an endpoint that does not allow them to divine information about a user beyond the specific endpoint channel. | |||
===Why "PlaceHolder Server"?=== | |||
placeholder is a temporary name while this document is being edited in order to prevent Wiki conflicts. | |||
In order to scale easily, a system should require the least amount of data necessary. While it would be ideal that there be no data exchanged, we realized that having a tiny amount would not alter the overall design or change the desired behaviors. | In order to scale easily, a system should require the least amount of data necessary. While it would be ideal that there be no data exchanged, we realized that having a tiny amount would not alter the overall design or change the desired behaviors. | ||
| Line 20: | Line 42: | ||
In addition, an App Server may wish to notify an App of an event or action and not be able to send a message directly to the App or device. | In addition, an App Server may wish to notify an App of an event or action and not be able to send a message directly to the App or device. | ||
To accomplish this, App Servers can send Version Events to Apps. A Version event is a simple, fire and forget "ping" style event that the | To accomplish this, App Servers can send Version Events to Apps. A Version event is a simple, fire and forget "ping" style event that the PlaceHolder Server will make a best effort to deliver to the App. | ||
There are a few Caveats that should be stated: | There are a few Caveats that should be stated: | ||
| Line 32: | Line 54: | ||
==Use Cases== | ==Use Cases== | ||
<b>An App wishes to be notified when new email arrives</b>. A User installs an <i>App</i> on a mobile device which notifies her when someone adds a note to her bulletin board. The <i>App</i> calls the Registration function, which returns an <i>EndPoint</i>. The <i>App</i> sends the <i>EndPoint</i> to the <i>AppServer</i> using the magic of "Not-Part-Of-This-Protocol". The <i>AppServer</i> stores the <i>EndPoint</i> in the User's information. When a new note is added, the <i>AppServer</i> fetches the <i>EndPoint</i> and PUTs a new version value to it. This alerts | <b>An App wishes to be notified when new email arrives</b>. A User installs an <i>App</i> on a mobile device which notifies her when someone adds a note to her bulletin board. The <i>App</i> calls the Registration function, which returns an <i>EndPoint</i>. The <i>App</i> sends the <i>EndPoint</i> to the <i>AppServer</i> using the magic of "Not-Part-Of-This-Protocol". The <i>AppServer</i> stores the <i>EndPoint</i> in the User's information. When a new note is added, the <i>AppServer</i> fetches the <i>EndPoint</i> and PUTs a new version value to it. This alerts PlaceHolderServer Client, which wakes the <i>App</i> and sends a version event via a registered callback. This causes the <i>App</i> to refresh it's messages (again using the magical "Not-Part-Of-This-Protocol" system), and User gets a screen full of adorable kittens. | ||
<b>An AppServer wishes to notify Apps of an update</b>. Since a server doesn't want to be deluged by millions of pings from devices every hour, the developers wisely decide to opt for a Push mechanism. Much like the other example, an <i>App</i> registers with | <b>An AppServer wishes to notify Apps of an update</b>. Since a server doesn't want to be deluged by millions of pings from devices every hour, the developers wisely decide to opt for a Push mechanism. Much like the other example, an <i>App</i> registers with PlaceHolderServer, gets an <i>EndPoint</i> which it relays to <i>AppServer</i>. <i>AppServer</i> then PUTs a '000' version to the <i>EndPoint</i> which triggers an "update" event for the App, which silently acknowledges that all is well. At some later time, <i>AppServer</i> PUTs '001' to the <i>EndPoint</i> which PlaceHolderServer relays to <i>App</i> which then updates itself using "Not-Part-Of-This-Protocol-Either". | ||
<b>An incoming request from a WebRTC </b>. Bob uses Ringo’s STAR webrtc service. Bob is using the Desktop browser, but the tab/window isn't open to the Ringo service. Alice makes a webrtc call from work to Bob. Bob sees a notification about an incoming call. | <b>An incoming request from a WebRTC </b>. Bob uses Ringo’s STAR webrtc service. Bob is using the Desktop browser, but the tab/window isn't open to the Ringo service. Alice makes a webrtc call from work to Bob. Bob sees a notification about an incoming call. | ||
| Line 49: | Line 71: | ||
;APP: A possibly third party provided Web Application located on a remote User Agent. The end consumer of VERSION EVENTS. | ;APP: A possibly third party provided Web Application located on a remote User Agent. The end consumer of VERSION EVENTS. | ||
;APPID: A globally unique identifier for a given App. | ;APPID: A globally unique identifier for a given App. | ||
; | ;PLACEHOLDER CLIENT: The application or library that acts as the intermediary between the APP and the PLACEHOLDER SERVER. This provides the APP with VERSION EVENT callbacks. | ||
; | ;PLACEHOLDER SERVER: The application or library that acts as the intermediary between the APP SERVER and the PLACEHOLDER CLIENT. This provides ENDPOINTs for the APP SERVER. | ||
;ENDPOINT: A URL which accepts VERSION updates to trigger eventual APP VERSION EVENT. | ;ENDPOINT: A URL which accepts VERSION updates to trigger eventual APP VERSION EVENT. | ||
;UAID: A globally unique identifier for a given User Agent. | ;UAID: A globally unique identifier for a given User Agent. | ||
;VERSION EVENT: A request from APP SERVER to notify an APP to take action. | ;VERSION EVENT: A request from APP SERVER to notify an APP to take action. | ||
==Requirements== | ==Requirements== | ||
[File:EditionServerDiagram.pdf A diagram of the | [[File:EditionServerDiagram.pdf]] A diagram of the PlaceHolderServer interaction points. | ||
# APP requests an ENDPOINT from the | # APP requests an ENDPOINT from the PLACEHOLDER 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, | # If not already present, PLACEHOLDER CLIENT shall generate a unique UUID4 Identifier for the UserAgent (UAID) | ||
# | # PLACEHOLDER CLIENT shall generate a unique UUID4 Identifier for the APP (<abbr title="Previously known as the CHID">APPID</abbr>) | ||
# | # PLACEHOLDER CLIENT shall send UAID, APPID and any additional information required for proprietary KICK to the PLACEHOLDER SERVER | ||
# | # PLACEHOLDER SERVER shall create an ENDPOINT for the UAID and APPID and return it to the PLACEHOLDER CLIENT. | ||
# If a KICK driver is present, | # If a KICK driver is present, PLACEHOLDER SERVER shall relay appropriate PLACEHOLDER CLIENT provided information to the KICK driver. | ||
# | # PLACEHOLDER CLIENT tenders the ENDPOINT to APP via callback. | ||
# APP | # APP is responsible for sending ENDPOINT to the APP SERVER via out of protocol specified means. | ||
# On VERSION EVENT, APP SERVER PUTs | # On VERSION EVENT, APP SERVER PUTs to the ENDPOINT | ||
# If a | ## VERSION values are NOT transmitted through the system and only act as a trigger. | ||
# If a | # If a PLACEHOLDER CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS. | ||
# If a | ## Version data commits and possible publication through the server must be performed in less than 5 seconds. | ||
# | # If a PLACEHOLDER CLIENT is NOT currently connected, an optional, proprietary KICK driver may be called to wake devices associated with the corresponding ENDPOINT UAID. | ||
# If there are VERSION EVENTS pending for requested UAIDs, | # If a PLACEHOLDER SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage. | ||
# PLACEHOLDER CLIENT connects to the PLACEHOLDER SERVER and shall identify a list of one or more UAIDs it is responsible for. | |||
# If there are VERSION EVENTS pending for requested UAIDs, PLACEHOLDER SERVER sends an UPDATE packet | |||
# If no VERSION EVENTS are pending for the requested UAIDs, PLACEHOLDER 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 PLACEHOLDER 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. | |||
# If no VERSION EVENTS are pending for the requested UAIDs, | # On receipt of UPDATE, PLACEHOLDER CLIENT shall return an ACK to the PLACEHOLDER SERVER. | ||
# During the transmission of the UPDATE, a | ## The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | ||
# On receipt of UPDATE, | ## Version information associated with a non-expired User Agent record is not discarded until acknowledged by the client. | ||
# The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | # The PLACEHOLDER CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback | ||
# | # User Agent record (including associated channels and version information) that have not been accessed during an "active use" period, may be dropped by the PLACEHOLDER SERVER | ||
# The | ## An unknown (or garbage collected) user agent record would need to re-register with PLACEHOLDER SERVER as if this is an initial connection. | ||
# Clients are the source of truth for the associated channels. | |||
## Channel discrepancies between the client and the server result in the server sending a request to client to reset. | |||
### TODO: Details on what a reset entails needed | |||
# UAIDs may be a globally unique 128 bit number | |||
# APPIDs are unique per UAID namespace | |||
# ENDPOINTs are Globally Unique | |||
# Data must be stored and managed in a highly responsive manner (low read/write latency) | |||
# PLACEHOLDER SERVER should support 1MM+ number of simultaneously connected clients | |||
# Connections should maintain as long as possible. A server should not break a connection because it's gone idle. | |||
# A PLACEHOLDER SERVER should attempt to retry a failed transmission to the client every 60 seconds. | |||
NOTE: a | NOTE: a PLACEHOLDER RELAY may be created by combining the polling aspects of the PLACEHOLDER CLIENT with the data management and KICK driver of the PLACEHOLDER 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 PLACEHOLDER SERVER has received an ACK for a given UAID, the PLACEHOLDER SERVER is under no obligation to retain that data, and proper relay of the VERSION EVENT is the PLACEHOLDER RELAY's problem. | ||
==Get Involved== | ==Get Involved== | ||