How do you manage lifecycle?
It is users responsibility to prepare client's configuration instance and pass it during PubNub client instantiation. As long as there is a reference to the client instance it will be alive. The initialized client doesn't perform any activities until activated by user commands.
How do you know you have active connection?
Client doesn't check for active connection on its own and instead relies on network API response.
On a user command, the client prepares a REST request to PubNub API and passes it to the networking API for processing. If there were no issues and the response arrived in time (timeout can be specified), the results are parsed and wrapped into objects which are returned using callbacks.
If there was an issue during request processing, networking API will return information about the error which will then be parsed and wrapped into objects and returned to the caller.
In case of network issues, Realtime API's will return status object with category set to PNNetworkIssuesCategory.
There are also a set of other error categories:
PNNetworkIssuesCategory - (in case there was no connection at the moment when the client tried to send request)
PNTLSConnectionFailedCategory - TLS handshake issues and in most cases because of poor connection quality and packets loss and delays.
PNTimeoutCategory - response was not received before specified timeout.
Heartbeat API can be used as way to detect when network issues appear. Heartbeats send a request at intervals (which is set during client instance configuration) and utilize observer's callback to report successful and failed attempts. There is a chance that the network will get spotty between calls to this API and the socket with active long-poll (subscribe API for realtime messages) may not notice those issues and listen for events from a broken pipe.
How can you tell where the connection abruptly terminated?
There are three status events which may tell what there is some network issues: PNTimeoutCategory and PNNetworkIssuesCategory. AngularJS V4 has exclusive statuses that can reveal deeper information about the network from the browser API's.
PNTIMEOUTCATEGORY
This status may arrive if non-subscribe request didn't receive a response from the server in time. This may happen only if:
- Issues on service itself.
- There is a proxy between client and PubNub service which didn't send the request or didn't return a response in time
- There are issues with spotty network signal quality (or a lot of noise on the band)
PNTIMEOUTCATEGORY>PNNETWORKISSUESCATEGORY
No connection at the moment when request has been sent. This status is returned immediately to calling API through callback.
PNTIMEOUTCATEGORY>PNNETWORKUPCATEGORY
This status is exclusive to AngularJS V4 and indicates that browser reported network stability and the SDK was instructed to reconnect. This status is going to be the first status fired after a connectivity disruption.
PNTIMEOUTCATEGORY>PNNETWORKDOWNCATEGORY
This status is exclusive to AngularJS V4 and indicates that the browser reported network instability and the SDK will lose connection to the host. This status will be fired, but there are no guarantees on the chain of events (subscribe may timeout first) depending on the browser.
PNTIMEOUTCATEGORY>WHAT IS THE RECONNECTION STATUS?
There is PNNetworkIssuesCategory which can be generated in the middle of client lifecycle while it subscribed to real-time data channels.
In case that this status arrives, client starts pinging PubNub services using Time API every 10 seconds. As soon as a request is processed successfully, client will try to restore subscription on channels on which it was subscribed previously. If configured to keep timetoken on subscription restore, client will try to catch up on missed messages.
When client completes subscription restore after PNNetworkIssuesCategory it will generate PNReconnectedCategory to notify observers what client has been reconnected to real-time data channels.
If more than 100 messages will arrive (from PubNub in-memory messages cache), it is better to use history API to fetch potentially missed messages. To be notified about this case, requestMessageCountThreshold should be set to 100 - this will tell client to send PNRequestMessageCountExceededCategory status.
Reconnection policies:
The Web JavaScript SDK relies on the browser networking events for reconnection tries, it does not ping on regular intervals in order to conserve resources.
Javascript signals network events using the following status on the callbacks:
- When the network vanishes, the SDK sends PNNetworkDown.
- When the network comes back, the SDK sends PNNetworkUpCategory.
To establish a catch up mechanism, record the timetoken for the last message received and perform a subscribe on PNNetworkUpCategory by calling pubnub.subscribe(channels=, channelGroups=, tim).
RECONNECTION MANUALLY
On some platforms, application owners have more visibility into networking conditions than the SDK. You can call the pubnub.reconnect() functionality on each of the SDKs to force the SDK to try and reach out PubNub.
How to handle 403's on active subscriptions?
403 response on a subscribe event occurs when Access Manager is enabled and the user doesn't have access to the channel or the grant TTL has expired. In this case you need to create a new auth key, grant access to the user (from your server) and subscribe again.
403 For more info please check: http://www.pubnub.com/docs/angularjs-javascript/pam-security#handling-permission-denied-errors