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.