Adaptive Retry

There are a variety of reasons why a SBD message may not get through from the RockBLOCK to the satellite.

Since this is a line-of-sight system, the most obvious cause of a link failure is an obstruction. However, it can be due to inter-satellite handoff or contention for satellite resources. The response codes indicate that the message failed, but do not always give a precise reason.

When a SBD session fails, the exception logic in your application should determine what action to take. Typically if a session fails once or twice, the application immediately initiates another session. If the resends fail beyond this, and a satellite is in view, there may be an issue with contention for satellite resources. In this case, it is better to incrementally adjust the time interval between the resend attempts.

A suggested retry scheme might be:

  1. Initiate SBD session
  2. If that fails attempt resend within a random time of 0-5 seconds (repeat 2x)
  3. If still unsuccessful wait a random time of 0-30 seconds before attempting a resend (repeat 2x)
  4. If these attempts fail, increment the delay to 5 minutes.

This logic should cover almost any anomaly with the network.

Adaptive Retry


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.