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.

Updated about a year ago

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.