Setting up your own push notification server for Windows 8 can be a challenge. Novices can easily become overwhelmed trying to work within a paradigm they aren't familiar with. Many developers would rather use Azure's platform than set up and manage their own solution.
Azure's comprehensive suite of services and compatibility with other mobile vendor's is appealing. It is also recognized for being easy to configure, powerful, highly available, and performant. There is little incentive for many organizations to choose to put their own system in place.
However, once developers are familiar with how they work, push notifications aren't so intimidating. Companies can avoid paying expensive cloud fees by rolling their own in a matter of hours. The following is a high-level discussion of how this can be done.
In the above picture, the purple
Windows box represents the client. This could be your Surface Pro or Nokia 920. The
Notification Client Platform is MS-speak for the API that Windows exposes to you for initiating the notification process. The green
Cloud Service box is your server.
WNS is a Microsoft-hosted service that keeps track of all Windows clients.
To understand why the process is convoluted, you need to first understand what problem push notifications are trying to solve. Up-to-date apps are only possible by either polling servers for changes at high frequencies or through server-initiated messaging. In order for a server to initiate a connection over traditional networks (HTTP / TCP / IP), there needs to be a persistent, long-term HTTP socket. All mobile platforms have a WNS equivalent: a server that manages a single long connection with a device in order to initiate message-sending instantaneously. Any app on the device can use this same communication channel since it is shared and communication is multiplexed to the correct recipient on the client.
Windows Push Notification Service (WNS): https://login.live.com
This is Microsoft's bridge that brokers connections between your server and any one of your clients. Clients initiate 'channels' with the WNS which are referenced in the form of URI's. The server authenticates and connects to the WNS in order to facilitate communication with any of the clients.
This MSDN article describes the process of sending a push notification in detail. Before transmitting any information, it is necessary to authenticate. To do this, the server needs to request and receive an access token. This access token will be used to identify the server when sending specific messages.
Using parameters that define your app (
client_secret), you send an HTTPS request to
https://login.live.com/accesstoken.srf. The response from this request includes the necessary credentials (
After this access token has been received, the server can begin sending messages to clients using their Channel URI's.
The most complex part of this whole process is managing the Channel URI's for every client. Each client must know to save (or update) their own URI on the server every time it changes. Thus, the server typically has some sort of persistent store (SQL Server) that keeps track of an identifying characteristic of the client and it's corresponding URI.
Once the server needs to make a push notification, it can perform a lookup in its database and send an HTTPS POST to the URI with a bunch of parameters set. There are many HTTP header values that should be set, but the most important is the
access_token that was negotiated earlier.
The body of this POST request contains the XML message according to the tiles, toast or badge schemas documentation.
Your server should also be set up to support SSL since each client will inform the server of its URI. This URI should be treated as a secret so that attackers can't send rogue notifications.
Every time the app is opened, it needs to send the client's channel URI to ensure the server can reference it. This is similar to an unlisted phone number. The only way to make the call is to have the recipient give you their phone number. This is done using the
Notification Client Platform API, specifically, the
As mentioned before, the URI that results from this call should be sent to your server so it can dial up the client.
From there, each client needs to just wait until a message comes down the pipe. This is done using the PushNotificationChannel class. You can find more details about how to do this online.
I went over how push notifications work in detail. You should understand why sending and receiving notifications can get complicated. Hopefully this helps you get most of the way there. And if not, thankfully there's Azure.