In the previous post - Understanding Microsoft Push Notifications for Windows Phones, you learned what push notifications (PN) are and why we need them. In this post, we’ll explain a little about how Microsoft Push Notification (MPN) service works behind the scenes and who the different players are.
There are three players in the push notification game:
You will soon realize that PN is essentially a backend play, where your cloud service and Microsoft Push Notification Service (MPN) play a major role.
When a cloud service wishes to send messages to a WP application when your application is not running, it has to use MPN, which is a hosted service in Windows Azure. The MPN Service will send the message in the form of a push notification message on behalf of the cloud service.
But before the cloud service can send notification messages to a WP device, your WP application needs to send some kind of identification that can be used by your cloud service when it POST messages to MPN Service, as shown below in the following image. The WP application opens a notification channel to the MPN service, shown as number 1. By doing so, the application indicates that it wishes to receive push notifications messages. When the channel is created, a subscription end point is created within the MPN servers that allows your cloud service to POST messages to that end point (on the MPN Server), which in return will forward your cloud service message to the target WP device via the that channel, identified by the URI used to POST the message. In response to opening the channel, the MPN server returns a URI to the WP application. This URI represents the notification channel that your cloud service needs to use, and it contains all the information associated with that subscription. This URI is the address to which your cloud application will do an HTTP POST to send a PN message to the device. It is the responsible of your WP application to pass this URI to the cloud service, shown as number 2.
Setting up the PN Channel
In order to send messages to a WP device, the cloud service needs to do an HTTP POST, indicated as number 3, a well formatted (in XML format and in accordance with the MPN protocol), to the URI that it received from the WP application in step 2. By doing so, the cloud service posts a notification request to the MPN service, which in turn routes the message as a Push Notification to the WP device as either a toast, a tile notification, or raw data directly to the running application depending on the type of notification that is sent, shown as number 4.
Once the WP device receives the PN via the Push Client, it routes the notification to Shell, which in turn can either update the application tile, show a toast if the application is not running, or send the notification message to the already running application.
And that's it. From here on everything else is a detailed implementation of your cloud service and your WP client application, which will be the topic of our next post.
whats happened to the pictures ??
But please fix the image, thanks!
Thanks, but please fix the image, thanks!
Great Post ,however I have few basic questions regarding the Unique Uri. I am developing a Stock Notification App,
where Server Needs to Notify WP App. So it should know the unique URI it got from WP app.Will this URI will always be same (WP app Registration Process with MPN) in the whole life time. OR every time APP will get a new URI from MPN which needs to be communicated to my Server.
2> My second question is ,Is there a way when my App on Phone A can send any notification to the same APP installed on Phone B using MPN (WITHOUT using any 3rd Service) ,i.e if APP on Phone A happened to know the unique URI of APP on Phone B.
Thanks for answering in detail especially about MPN's possible downtime, MPN's security and other important questions.
I don't seem to be able to ping you. I am interested in learning about the "Throttle Mode" you mentioned. Can you please send me any information you might have on this process, i.e. cost, any limitations of using it? Is it slower?
Thanks for the insightful post. I am also interested in you answer to
itworx.research' post: what happens to the notifications when the device is inactive?
On the same topic, what is the best practice to ensure the cloud service doesn't "blindly" send notifications to the MPN service (when the device is inactive):
- have the cloud service check with the device to see if it is active?
- set-up a callback registration request? According to MSDN : "After a callback is registered, if the device transitions into an inactive state, the Microsoft Push Notification Service will send the message to the callback URI"
Thanks for the post and for addressing vivek_r_waghmare's questions. I have one more question regarding how MPNS service works.
Q: What if the cloud service posts a notification while the recipient's phone is turned off? Does MPNS lose the notification altogether? Does it retry sending the notification at a later time?
What's the SLA for time it takes to turn around a notification. Say, PhoneA wants to send a notification to PhoneB because your in a social media application and wanting to hit on a girl across the bar and have PhoneB pop-up a "You're being hit on!". Is this milliseconds, seconds or minutes?
Great post. Thank you so much for elaborating MPN service in detail.
However, I have following question/s -
1) In the step 1, WP application opens the communication channel between MPNS and device Push Client. Is this connection will remain alive? In other way, What if the communication channel will get closed due to network problems?
2) As per my understanding, PUSH notification should be initiated by the Cloud service. I mean, MPNS has to send the first request to phone device and then phone device has to acknowledge the request. However, in case of WP PN, Push Client has to always send request first to MPN service asking any messages for the specific aqpplication. So it is as good as Polling and not the Pushing. Kindly, correct me if I have misunderstood something.
@Nevor - you dont have to pay for the first 500 messages. But you have to use MSPN servers to push Push Notification messages to the phone
And what if I don't trust microsoft or don't want to pay to send messages, I cannot send a PN to the phone directly ? It is kind of surprising
Answering some of the questions (@vivek_r_waghmare)
Q: What about the security of messages which will flow through MPNS
A: The channel Between MPNS and the phone (indicated by number 1 and 4 in the above image) is secured (TLS). The other channels, mainly between your application backend and MPNS are not secured by default. However with specific agreement you can opt-in to "throttle mode" which gives you secure channel and "no limit" on number of messages... if you are interested in such a channel, ping me.
Q: If i deploy my app over many WP7 phone, do they share same return URL from MPNS, or Each deployed app on different will have differet URL
A: The URI is unique per application per phone. That is each of your users (assuming different phone devices) will yield a different URI.
Q; If the answer to same app on different phone have different URL, how can i broadcast message to all deployed applications. Is there any inbuild support?
A: In this current version, we do not support broadcast functionality from the back-end. Can you please share the specific scenario you have in mind?
Q: As my cloud/service communication with its WP7 companion app, depends on MPNS, what if MPNS goes down?, is there any way i can use my custom Push notificaion clients and Service, instead of using MPNS
A: In short, MPNS runs on Windows Azure, therefore we "hope" it will NOT have any downtime. If it does happen, there is no way you can "private" channel that override the system. Let's hope we dont get to this...
Q: Is there any Fee for using MPNS
A: In short the answer is yes and no. There is no charge for up to 500 messages per 24 hr per URI. Back to answer #2, that mean you can send (between your back-end and MPNS ) up to 500 messages. With that said, if you need to go above 500 messages per URI (per app per device per 24 hours) then you can opt-in to the throttle mode which as indicated in answer #1, you can go beyond 500 messages and use secure channel
Great intro articles on MPN. One thing I've never quite understood about PN services is how does the MPN service reduce the power consumption of the device. Doesn't it also need to poll the MPN server in the cloud to check for notifications? Does it save on battery life by consolidating the various application polls into one request at a time instead of various requests for each of the cloud applications?
Please, answer all vivek_r_waghmare's questions. I'm too curious...
Thank you very much for the two posts about the MPN.
As for the doubts of vivek...
I would add my interest in an answer for number 1, 4 and 5
as my guess for 2 and 3 are that there are some mechanisms to id a specific device after it has requested to receive mpn for a specific app.
As for me, i would add a request for some further posting about a specific topic i am very interest in.
- The powermodel of windows phone 7
(how it differs from windows mobile 6 and how it works)
Is there any chance to see a post concerning this topic in the near future?
Thanks in advance for any answer.
Thanks for Providing details of MPN, I have following doubts
1. What about the security of messages which will flow through MPNS.
2. If i deploy my app over many WP7 phone, do they share same return URL from MPNS, or Each deployed app on different will have differet URL
3. If the answer to same app on different phone have different URL, how can i broadcast message to all deployed applications. Is there any inbuild support?
4. As my cloud/service communication with its WP7 companion app, depends on MPNS, what if MPNS goes down?, is there any way i can use my custom Push notificaion clients and Service, instead of using MPNS
5.Is there any Fee for using MPNS
thanks for the article do you think you could give us some sample code & step by step guide to see more precisly how to do it.
Sorry my previous for that KIN post. Am so sorry!
WOW! before I read that post of KIN. You didn't specify the price. Well if you ask me honestly I would like to buy the cheaper on KIN 1 because I don't have that much amount to pay $100. LOL. Anyways I liked that phone as soon as it was announced. Many thanks and congratulations to you guys.