Transports and connections
      Back to home
      1. Ably FAQs
      2. Ably architecture, transports, and security
      3. Transports and connections

      Connection state recovery

      It is very common for devices to have constantly changing network conditions as a result of changing from a mobile data network to a wifi network, being in a tunnel for a short period, or perhaps due to intermittent network issues. We believe that developers shouldn't have to worry about service continuity when the connection is reestablished, and as such we ensure that the connection state for a client is retained on our servers whilst the client is disconnected. 
       
      When an Ably Realtime client is disconnected abruptly, it moves into the disconnected state and will reconnect automatically.  By default, when in the disconnected state, our client libraries will keep trying to connect every 15 seconds and also whenever the OS notifies the client library that the internet connection has returned.  The client library remains in the disconnected state for a maximum of 2 minutes as this is the amount of time our servers will retain a disconnected client's connection state for.  
       
      Whilst a client is in the disconnected state, it is safe to assume that when a connection is reestablished by that client, all channels will remain attached and any messages published whilst disconnected will be delivered upon reconnection.  This is possible because Ably holds onto the connection state for 2 minutes following an abrupt disconnection, and thus queues all messages published on all the channels the client was subscribed to.  Once the client is reconnected, the queued messages for each attached channel are delivered immediately.

       

      However, once the client has been disconnected for more than 2 minutes, the client library moves into the suspended state indicating that all connection state is lost.  As such, all channels are automatically suspended at this point too indicating that channel continuity is not possible.  Once the connection is reestablished, the client library will reattach the suspended channels automatically and emit an attached event with the resumed flag set to false.  This ensures that as a developer, you can listen for attached events and check the resumed flag to see if a channel resumed fully and no messages were lost (when resumed is true), or the channel attached but could not resume (when resumed is false).  If channel continuity is not possible, then typically if historical messages are important to you, you would use the history API to retrieve all older messages, with the untilAttach flag set to true. Find out more about nonfatal channel errors and how to handle them.

       

      See the realtime connection documentation for more information on connection state management.

       

      Commonly asked questions

       

      • How many messages will you store whilst a client is disconnected?
        There is no hard limit so we will in almost all circumstances be able to keep all messages for two minutes.
      • What happens if messages cannot be replayed or the connection cannot be recovered?
        If the connection is not able to be recovered, Ably notifies the client and the client will reattached the channels and emit an attached event with the resumed flag set to false.  As a developer, this gives you certainty and predictability you need to build a reliable application.  If a channel is not resumed successfully (i.e. Ably cannot guarantee you have not missed messages since you were last attached), then you will need to decide what action you may take, including potentially retrieving the history of that channel via our history API.