The respondent protocol is one half of a survey pattern. In this pattern, a surveyor sends a survey, which is broadcast to all peer respondents. The respondents then have a chance to reply (but are not obliged to reply). The survey itself is a timed event, so that responses received after the survey has finished are discarded.
|
Tip
|
This protocol is useful in solving voting problems, such as leader election in cluster configurations, as well as certain kinds of service discovery problems. |
The respondent protocol is the respondent side, and the surveyor protocol is the surveyor side.
The nng_respondent0_open() functions create a
respondent socket.
This socket may be used to receive messages, and then to send replies.
A reply can only be sent after receiving a survey, and generally the
reply will be sent to surveyor from whom the last survey was received.
Respondents may discard a survey by simply not replying to it.
Raw mode sockets (set with NNG_OPT_RAW)
ignore all these restrictions.
This protocol supports the creation of contexts for concurrent
use cases using nng_ctx_open().
Incoming surveys will be routed to and received by only one context. Additional surveys may be received by other contexts in parallel. Replies made using a context will be returned to the the surveyor that issued the survey most recently received by that context. The restrictions for order of operations with sockets apply equally well for contexts, except that each context will be treated as if it were a separate socket.
Only version 0 of this protocol is supported. (At the time of writing, no other versions of this protocol have been defined. An earlier and incompatible version of the protocol was used in older pre-releases of nanomsg, but was not released in any production version.)
The respondent protocol uses a backtrace in the header. This is more fully documented in the surveyor manual.