Confirmed users
1,018
edits
CloudServices/Roadmaps/EditionServer: Difference between revisions
CloudServices/Roadmaps/EditionServer (view source)
Revision as of 16:37, 25 March 2013
, 25 March 2013→Requirements
| Line 66: | Line 66: | ||
# If a KICK driver is present, PLACEHOLDER SERVER shall relay appropriate PLACEHOLDER CLIENT provided information to the KICK driver. | # 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. | # 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 | ||
## VERSION values are NOT transmitted through the system and only act as a trigger. | |||
# If a PLACEHOLDER CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS. | # If a PLACEHOLDER CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS. | ||
## 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 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 a PLACEHOLDER SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage. | # If a PLACEHOLDER SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage. | ||
| Line 80: | Line 82: | ||
# 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. | # 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. | ||
# On receipt of UPDATE, PLACEHOLDER CLIENT shall return an ACK to the PLACEHOLDER SERVER. | # On receipt of UPDATE, PLACEHOLDER CLIENT shall return an ACK to the PLACEHOLDER SERVER. | ||
# The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | ## The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | ||
# | ## Version information associated with a non-expired User Agent record is not discarded until acknowledged by the client. | ||
# The PLACEHOLDER CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback, and passing the VERSION | # The PLACEHOLDER CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback<strike>, and passing the VERSION</strike> | ||
# 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 | |||
## An unknown (or garbage collected) user agent record would need to re-register with PLACEHOLDER SERVER as if this is an initial connection. | |||
<strike> | |||
* Version data is significant and must reflect the latest value submitted. Must be numeric. | |||
** Version must be higher than previously submitted value (TODO: Need to provide use case for how versions would be required) | |||
</strike> | |||
(The following are true for the protocol, however may not be true for the Mozilla Implementation of this server) | |||
* 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. | |||
* Details on what a reset entails needed | |||
* UserAgent IDs are globally unique 128 bit numerics | |||
* ChannelIDs are unique per UserAgentID namespace | |||
* Endpoints are Globally Unique | |||
* Data must be stored and managed in a highly responsive manner (low read/write latency) | |||
* Service 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 Server should attempt to retry a failed transmission to the client every 60 seconds. | |||
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. | 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. | ||