Push Notification Status

Push Notification Status

  • Comments 5
  • Likes

There have been a number of discussions about Push Notification connections and in particular the “OK/Received/Connected/Active” and “OK/Received/Temporarily Disconnected/Active” states.  We’d like to take a few moments in this blog post to review how the connections work.

As indicated in the MSDN documentation, there are a number of Push Notification Service Response Codes.

The “OK/Received/Connected/Active” status typically signals that everything is operating normally but you should keep the following points in mind:

  • This status does not mean the device has received the notification.  It only indicates that the server has received the notification and queued it for delivery at the next possible opportunity for the device.
  • The server could respond with this status even though the device is currently transitioning into an unreachable state.  This means the notification would not be delivered until the device returns from the unreachable state.
  • Remember there are different batching intervals you can choose for a notification, so the notifications will arrive based on the batching interval you specified.

The “OK/Received/Temporarily Disconnected/Active” status can occur for a variety of reasons, including but not limited to:

  • In order to reduce network load and latency, mobile operator network configurations can vary greatly in the amount of time a persistent data connection is allowed to live.  The Push Notification Client attempts to mitigate these persistent data connection limitations, but there is a lower bound after which it is power inefficient to mitigate this situation.  This may lead to devices experiencing the “OK/Received/Temporarily Disconnected/Active” state as a result of the data connection being interrupted.
  • The device is outside the coverage area of their carrier and the user has chosen to disable data connection when roaming.
  • The device has a Pay-As-You-Go plan and has temporarily disabled the data connection or has a restrictive data plan option.
  • The device is on the edge of a coverage area and the data connection is not reliable.
  • If Wi-Fi is being used and cellular data is not available, the device must have a clear path to the internet in order for push notifications to be received – this can be problematic on some corporate networks.
  • The device is alternating between cell and Wi-Fi connections and the connection is not in a steady state.

Also note that the Push client cannot work behind a SOCKS proxy.  If your device transitions to a network that requires a SOCKS proxy, you will not be able to use the Push service.

These are all conditions valid in the real world so developers should actively code for the “Temporarily Disconnected” state in their applications.   One challenge in development is that the emulator is not subject to these real world conditions and will always have a reliable connection.  Therefore notifications that work reliably in the emulator may not work reliably in the real world.  If a connection is not in a reliable state, developers may want to throttle back the number of notifications until a normal state is achieved.   If the DeviceConnectionStatus becomes “Inactive”, then the web service should only attempt one notification per hour until a normal connection is resumed.  Developers can review the Push Notification Server Side Helper for WP7 article and download the code for some samples of handling the server response codes.

Since the configurations of mobile operator networks are all different, the delivery of Push Notifications may vary.  Microsoft works closely with our mobile operator partners to ensure consistent delivery where possible but developers should test across multiple mobile operator networks when feasible.

By programming defensively around real world connection states, developers can gracefully degrade functionality in their applications.  As we move forward with future versions, we’ll work to make this easier and more reliable for developers.

5 Comments
You must be logged in to comment. Sign in or Join Now
  • andycted
    43 Posts

    Quick update.

    Today I've done two exact tests, one with wifi, one with mobile network.

    The result is exactly the same.

    Let's start when (if !) push notifications works. I push a toast or a tile, receive it, then setup a timer which will send it in about 15 minutes (or wait and send it manually after 15 minutes, it's the same).

    10% of the times it works, 70% of the times I get TempDisconnected straight at this second push, 20% of the times I get a Connected, BUT the toast/tile doesn't get through all the same ! The next automatic or manual push I send, gets a TempDisconnected. From then on, it's basically semi-random, some times I get the pushed toasts/tiles after about an hour, sometimes after two, sometimes they're totally lost. Once or twice the delay wasn't so bad, like 20 minutes, which is still too much but I actually could live with it.

    To me, this fact and the reliability of hotmail push, is proof that the system is broken and that it hasn't got a lot to do with mobile network operators

  • andycted
    43 Posts

    As mentioned in the app hub forums, there is still no solution for this problem, even after NoDo.

    Setup:

    - Wifi with clear path to internet, charger plugged in, lockscreen off: TempDisconnected after half an hour

    - No Wifi, excellent 3G connection, charger plugged in, lockscreen off: TempDisconnected after minutes

    The situation stays like that for hours, then randomly works for a few hours then back to broken.

    The only conclusion I can think of is that Push Notifications stack is totally broken.

    This is a big huge problem, because users are loudly asking for live tiles in my apps, which work perfectly in the emulator but not at all in the phone !

  • NiallG
    10 Posts

    How about addressing the real white elephant in the room - ShellTileSchedule - which doesn't work very well at all and get's disabled by the o/s quite regularly. There's no way for developers to program defensively around it - as the logic is 100% controlled by the o/s. Quite obviously the o/s developers assumed perfect world conditions and didn't apply any defensive logic whatsoever.

    I can't seem to get any answer from anyone whether this problem is being addressed or if any fixes are forthcoming at all. I've had a gutful getting bad reviews from end users because of live tile problems (which an end user blames the app for and not the o/s).

    Please do something about this...

  • Great post and some very good information, although....

    Like the person above me i am experiencing the Temporarily Disconnected

    messages more often than logical.

    I am a developer of the app My Football, which is a soccer app which does Toast and Tile for a few thousand users. A lot of users are complaining that they get their messages too late.

    If it wasn't for myself, the main developer of this app to have this issue also. I am every 40 minutes of an hour TempDisconnected while sitting next to a Wifi router and having full 3G data connection.

    In my experience, which i tested with M. Hoekstra of Microsoft the Netherlands, it is mainly provider related. These are some carriers where users with my app had these problems:

    - O2 UK

    - AT&T US

    - T-Mobile NL

    Carrier Vodafone NL doesn't have this problem at all, so you's think it's carrier related with the Time-out settings you mention in the post.

    To me even stranger is, these 3 carriers are also the main carriers in their country of that other phone from Cupertino.

    ps. I also hope you guys would make automatic settings to enable/disable push for an app, because users are bumping into the limit of max allowed push apps.

  • axelriet
    11 Posts

    First sensible advice I've read concerning this topic. Most of the time previous articles relied on limited testing done on the emu, and none acknowledged the fact that real devices operated vastly differently with respect to push notifications (probably because there authors never bothered testing on an actual device…).

    It's actually even worse that what you describe, as a perfectly connected device (3G+Wifi, steady and very well connected with direct path to internet) can still experience /all/ the issues you mentioned, and the message delivery is sometimes delayed up to /several ours/ for no apparent reasons.

    I saw this occur with the device sitting right next to me on tap power, 1 meter from a Wifi router and less than 100m from the next GSM relay, with five bars of signal. By contrast, provided that the device in in one of the 219 countries covered by GSM, SMS delivery is *much* more reliable (perfectly reliable and dependable, actually), as in “always work” - when the device is connected - even across multi-carrier roaming, and did for the past couple of decades. WP7 push is nice and promising, but still has a very long way to go to come anywhere near, in particular you can completely forget WP7 push in its current form for anything that needs to be "reasonably real-time" or "reasonable reliable".