axl_bool vortex_channel_send_rpy ( VortexChannel channel,
const void *  message,
size_t  message_size,
int  msg_no_rpy 
)

Allows to send a message reply using RPY type.

Sends a RPY message to received message MSG identified by msg_no_rpy. This functions allows you to reply a to a received MSG in a way you only need to provide the msg_no_rpy. According to RFC3080: the BEEP Core, a message reply can not be done if there are other message awaiting to be replied.

This means calling to vortex_channel_send_rpy trying to send a reply having previous message been waiting for a reply yields to block caller until previous replies are sent.

These may seems to be an annoying behavior but have some advantages and can be also avoided easily. First of all, think about the following scenario: a vortex client (or beep enabled client) sends over the same channel 3 request using 3 MSG frame type without waiting to be replied.

Beep RPC 3080 section "2.6.1 Withing a Single Channel" says listener role side have to reply to these 3 MSG in the order they have come in, if they have entered through the same channel. This ensure client application that its request are sent in order to remote server but also its reply are received in the same order.

This feature is a really strong one because application designer don't need to pay attention how message replies are received no matter how long each one have taken to be processed on the server side.

As a side effect, it maybe happen you don't want to get hanged until reply is received just because it doesn't make sense for the application to receive all replies in the same order msg were sent.

For this case client application must send all msg over different channel so each MSG/RPY pair is independent from each other. This can also be found on RFC 3080 section "2.6.2 Between Different Channels"

As a consequence:

  • Message sent over the same channel will receive its replies in the same order the message were sent. This have a "serial behavior".

    NOTE: Take also a look into vortex_channel_set_serialize to avoid thread planner decisions that could make frame received handlers to "appear" to be invoked in an unordered fashion.

  • Message sent over different channels will receive replies as fast as the remote BEEP node replies to them. This have a "parallel behavior"

Parameters:
channel the channel where the message will be sent
message the message to sent
message_size the message size
msg_no_rpy the message number this function is going to reply to.
Returns:
axl_true if message was queued to be sent, otherwise axl_false is returned.
NOTE: See MIME considerations described at vortex_channel_send_msg which also applies to this function.