The subscription ID is now officially a part of the RMr message (available with routing since v1.0.19). It is available in the same way that the message type is: directly from the rmr_mbuf_t struct. The field was added at the end of the user accessible fields to minimize the potential for breaking wrappers, but that potential is there. The field in the actual message is a 32 bit, signed integer. The 'unset' or 'invalid' subscription id is -1 and messages will be initialized with this value.


Messages sent via rmr_send_msg(), rmr_rts_msg(), and rmr_call() can be routed in one of two ways:

  • Using only the message type (original)
  • Using both the message type and the subscription ID (where the subscription ID is assigned by a subscription manager)


When an application has a message which must be sent with a subscription ID, it must add that ID into the message in the same way that the message type is added. The following code shows both being added prior to sending the message:


sbuf->mtype = mtype;          // add the message type
sbuf->sub_id = subscribers[i] // add the subscription ID


IMPORTANT:   When reusing or resending a message, the application should ensure that the subscription ID field is cleared if it is not needed. The field is cleared by setting it to RMR_VOID_SUBID (defined in rmr.h)

  • No labels

1 Comment

  1. Hello,

    I have a quick question regarding RMR library in osc github.

    I just have found that the send_msg API picks only one destination if mutiple xapps are subscribing the same sub id and message type.

    May I know if it is intended or a bug?