Analysing rep.c / nn_rep_recv, my understanding is that the backtrace (channel IDs stack) is stored in the socket and that if the REP socket receives a second message before nn_rep_send was performed on the first one, then the first message is cancelled. Do you confirm ?
For intermediate devices, I can imagine the send is prioritary over the receive. Then I assume no message is cancelled. But for an end point, say a worker, what happens if the worker processing is long compared to the typical requests interval ? Isn't the service down as all messages may be cancelled ?
Le 13/01/2014 17:37, Laurent Alebarde a écrit :
Le 13/01/2014 15:30, Martin Sustrik a écrit :If you're patch is generic enough we can even merge it to nanomsg to be switched on by a socket option or such. MartinNice. To speed-up my understanding please, a few more questions:The REQ/REP end-to-end feature described here (https://raw.github.com/nanomsg/nanomsg/master/rfc/sp-request-reply-01.txt), that enables the answer to go back to the right REQ node works in which additional conditions ?If I build intermediate REP/REQ nodes with nn_recv and nn_send of the API, that makes use of void* buffers, I understand that from a receive to the send, I loose the message header and then the channel IDs stack ? So here, it does not work ?Does it work only with nn_sendmsg / nn_recvmsg which manipulate the header ? So device manages it ?Could you explain struct nn_iovec, struct nn_msghdr and nn_device_mvmsg working ?Cheers, Laurent
