User:Jrconlin/SimplePushServer: Difference between revisions
Jump to navigation
Jump to search
(Created page with "= Simple Push Server = This document was created as a worksheet for the server back-end for WebAPI/SimplePush. This document presumes you have read that document (It's shor...") |
No edit summary |
||
| Line 7: | Line 7: | ||
;client : the agent process acting on behalf of the <i>RECIPIENT</i> | ;client : the agent process acting on behalf of the <i>RECIPIENT</i> | ||
;update: an occurrence of interest to the <i>CLIENT</i> | ;update: an occurrence of interest to the <i>CLIENT</i> | ||
; | ;publisher : the generator of <i>NOTIFICATION</i>s for <i>UPDATES</i>s | ||
;notification : a message from <i> | ;notification : a message from <i>PUBLISHER</i> to <i>CLIENT</i> indicating <i>UPDATES</i> | ||
;server : the NOTIFICATION relaying system between the <i>CLIENT</i> and <i> | ;server : the NOTIFICATION relaying system between the <i>CLIENT</i> and <i>PUBLISHER</i> | ||
;topic : a label to identify <i>CLIENT</i> interest for <i>NOTIFICATIONS</i> from <i>SERVER</i> | ;topic : a label to identify <i>CLIENT</i> interest for <i>NOTIFICATIONS</i> from <i>SERVER</i> | ||
;windowed polling : a <i>CLIENT</i> opens a connection to the <i>SERVER</i> every 5 minutes. If the <i>SERVER</i> has <i>NOTIFICATION</i>s for <i>CLIENT</i>, <i>CLIENT</i> will poll more frequently, adding time between each poll that returned no results. | ;windowed polling : a <i>CLIENT</i> opens a connection to the <i>SERVER</i> every 5 minutes. If the <i>SERVER</i> has <i>NOTIFICATION</i>s for <i>CLIENT</i>, <i>CLIENT</i> will poll more frequently, adding time between each poll that returned no results. | ||
| Line 15: | Line 15: | ||
== Short Requirements List == | == Short Requirements List == | ||
# clients register a topic with a | # clients register a topic with a publisher. | ||
# Notifications carry no data other than the topic | # Notifications carry no data other than the topic | ||
## Actions to perform for each topic are dependent on the client. | ## Actions to perform for each topic are dependent on the client. | ||
| Line 23: | Line 23: | ||
== Outstanding questions == | == Outstanding questions == | ||
# Q: Is the topic name provided by the server? | # Q: Is the topic name provided by the server? | ||
# Q: Should the topic be unique between client and | # Q: Should the topic be unique between client and publisher, or could there be a "broadcast" for all clients of a topic? | ||
# Q: Should there be an option for notification routing? (e.g. server to server for mobile platforms) | # Q: Should there be an option for notification routing? (e.g. server to server for mobile platforms) | ||
| Line 31: | Line 31: | ||
There are some considerations for a more "home grown" effort: | There are some considerations for a more "home grown" effort: | ||
* PubSub uses XML as it's data transport layer, this can be problematic on platforms that are optimized for JSON. | * PubSub uses XML as it's data transport layer, this can be problematic on platforms that are optimized for JSON. | ||
* PubSub is | * PubSub is publisher focused. Publishers ping PubSubHub, which pulls data and pushes to clients. Depending on implementation, [https://code.google.com/p/pubsubhubbub/wiki/ComparingProtocols Publishers] may still be hit by Thundering Herds. | ||
* Notifications are more broadcast in nature, meaning that single topics are possible, but potentially expensive to maintain. | * Notifications are more broadcast in nature, meaning that single topics are possible, but potentially expensive to maintain. | ||
None of these are strong arguments, however. | None of these are strong arguments, however. | ||
Latest revision as of 21:54, 6 November 2012
Simple Push Server
This document was created as a worksheet for the server back-end for WebAPI/SimplePush. This document presumes you have read that document (It's short, go do it).
Definitions
- client
- the agent process acting on behalf of the RECIPIENT
- update
- an occurrence of interest to the CLIENT
- publisher
- the generator of NOTIFICATIONs for UPDATESs
- notification
- a message from PUBLISHER to CLIENT indicating UPDATES
- server
- the NOTIFICATION relaying system between the CLIENT and PUBLISHER
- topic
- a label to identify CLIENT interest for NOTIFICATIONS from SERVER
- windowed polling
- a CLIENT opens a connection to the SERVER every 5 minutes. If the SERVER has NOTIFICATIONs for CLIENT, CLIENT will poll more frequently, adding time between each poll that returned no results.
Short Requirements List
- clients register a topic with a publisher.
- Notifications carry no data other than the topic
- Actions to perform for each topic are dependent on the client.
- Multiple Notifications for a client for a topic collapse to a single Notification
- Notifications are delivered from server to client via windowed polling, in order to reduce live socket costs.
Outstanding questions
- Q: Is the topic name provided by the server?
- Q: Should the topic be unique between client and publisher, or could there be a "broadcast" for all clients of a topic?
- Q: Should there be an option for notification routing? (e.g. server to server for mobile platforms)
Thoughts
The requirements for this system seem to align fairly closely with a PubSub model. I would recommend not creating a new system from scratch, but instead running a simple PubSubHubBub node
There are some considerations for a more "home grown" effort:
- PubSub uses XML as it's data transport layer, this can be problematic on platforms that are optimized for JSON.
- PubSub is publisher focused. Publishers ping PubSubHub, which pulls data and pushes to clients. Depending on implementation, Publishers may still be hit by Thundering Herds.
- Notifications are more broadcast in nature, meaning that single topics are possible, but potentially expensive to maintain.
None of these are strong arguments, however.