int sxmsg_reply(sxmsg_t *msg, const char *data, size_t datalen);
int sxmsg_reply_pp(sxmsg_t *msg, const char *data, size_t datalen);
.br
.sp
.SHDESCRIPTION
.Bsxmsg_reply
Will reply to the message pointed by
.Bmsg
and awaits for the reply from the peer. It will attach the data pointed by
.Bdata
with length in bytes pointed by
.Bdatalen.
This message will be sent within context of the calling thread.
.br
.Bsxmsg_reply_pp
Will do exactly the same, but message sending will be postponed and sent by one of the thread serving the underlying connection link.
.br
Both calls will cause a sleep of the calling thread until reply or error will be returned. I.e. this call is blocking one. Also, message is actually atom of the dialog, that means one side sending a first message creates dialog, other side may or may not close this dialog with error code (actual a message without data) or with some data, you should track the message return code to correctly close dialogs.
.br
If dialogs will be not finished correctly the limit of active messages will be exceeded and you will be not able to create a new dialog while message poll is full with opened dialogs. It's a good practice to avoid long dialog queues in critical operations or operations required to send a lot of data, since each message can take a lot of time (SSL time, network time).
.br
.SHRETURNVALUE
Dialog will be closed in all cases except the following error codes returns: