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

1. clients register a topic with a publisher.
2. Notifications carry no data other than the topic
   1. Actions to perform for each topic are dependent on the client.
   2. Multiple Notifications for a client for a topic collapse to a single Notification
3. Notifications are delivered from server to client via windowed polling, in order to reduce live socket costs.

Outstanding questions

1. Q: Is the topic name provided by the server?
2. Q: Should the topic be unique between client and publisher, or could there be a "broadcast" for all clients of a topic?
3. 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.