Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
OS Components & Operations
High Availability Framework Developer's Guide
Using the Client Recovery Library
MsgSend*() functions

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
  - Adaptive Partitioning User's Guide
  - Boot Optimization Guide
    The Boot Optimization Guide describes techniques you can use to reduce the time from your board's initial power on until you have a fully functional QNX system running on the board.
  - Building Embedded Systems
    The Building Embedded Systems guide is intended for developers who are developing or building BSPs for QNX Neutrino RTOS embedded systems.
  - Core Networking Stack User's Guide
    This guide introduces you to the QNX Neutrino Core Networking stack and its manager, io-pkt.
  - Customizing a BSP
    While QNX provides Board Support Packages (BSPs) for many common platforms and their individual variants, in some cases, you need a BSP for a board that QNX does not provide. If this is the case, you can modify a QNX BSP or develop your own.
  - Device Publishers Developer's Guide
  - High Availability Framework Developer's Guide
  - High-Performance Networking Stack (io-sock) User's Guide
    This guide contains instructions for implementing and using the QNX Neutrino High-Performance Networking Stack and its manager, io-sock.
  - Instant Device Activation
  - Migrating to QNX SDP 7.1
  - PCI Server User's Guide
  - Persistent Publish/Subscribe Developer's Guide
  - Platform-independent Publish/Subscribe Developer's Guide
    This guide is intended for application developers who want to use the Platform-independent Publish Subscribe (PiPS) framework to exchange information with other applications. First, the overall PiPS design and data-exchange model are explained. Then, tutorials on using PiPS are given. These tutorials cover key tasks such as selecting a publish-subscribe provider to use and writing plugins that read and write custom data types.
  - QDB Developer's Guide
  - QNX Helpers Developer's Guide
    These libraries provide QNX helpers, including helpers that assist with logging, string conversion, and number and type sizes.
  - SMMUMAN User's Guide
  - System Analysis Toolkit (SAT) User's Guide
  - System Architecture
    The System Architecture guide accompanies the QNX Neutrino RTOS and is intended for both application developers and end-users.
  - Technotes
  - User's Guide
    The QNX Neutrino User's Guide is intended for all users of a QNX Neutrino RTOS system, from system administrators to end users.
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

MsgSend*() functions

Normally, the MsgSend*() functions return EBADF or ESRCH when a connection is stale or closed on the server end (e.g., because the server dies). In many cases, the servers themselves return (e.g., they're restarted) and begin to offer the services properly almost immediately (in an HA scenario). Rather than merely terminate the message transmission with an error, in some cases it might be possible to perform recovery and continue with the message transmission.

The HA library functions that cover all the MsgSend*() varieties are designed to do exactly this. When a specific invocation of one of the MsgSend*() functions fails, a client-provided recovery function is called. This recovery function can attempt to reestablish the connection and return control to the HA library's MsgSend*() function. As long as the connection ID returned by the recovery function is the same as the old connection ID (which in many cases is easy to ensure via close/open/dup2() sequences), then the MsgSend*() functions can now attempt to retransmit the data.

If at any point the errors returned by MsgSend*() are anything other than EBADF or ESRCH, these errors are propagated back to the client. Note also that if the connection ID isn't an HA-aware connection ID, or if the client hasn't provided a recovery function or that function can't re-obtain the same connection ID, then the error is allowed to propagate back to the client to handle in whatever way it likes.

Clients can change their recovery functions. And since clients can also pass around recovery/connection information (which in turn is passed by the HA library to the recovery function), clients can construct complex recovery mechanisms that can be modified dynamically.

The client-side recovery library lets clients reconstruct the state required to continue the message transmission after reconnecting to either the same server or to a different server. The client is responsible for determining what constitutes the state that must be reconstructed and for performing this appropriately while the recovery function is called.

Page updated: March 12, 2026