|This documentation is for the TIP (development tree) of NNG and may represent unreleased changes or functionality that is experimental, and is subject to change before release. The latest released version is v1.3.2. See the documentation for v1.3.2 for the most up-to-date information.|
nng_rep - reply protocol
(protocol, rep) The rep protocol is one half of a request/reply pattern. In this pattern, a requester sends a message to one replier, who is expected to reply. The request is resent if no reply arrives, until a reply is received or the request times out.
|This protocol is useful in setting up RPC-like services. It is also reliable, in that a the requester will keep retrying until a reply is received.|
The rep protocol is the replier side, and the req protocol is the requester side.
nng_rep0_open() functions create a replier socket.
This socket may be used to receive messages (requests), and then to send
Generally a reply can only be sent after receiving a request.
Send operations will result in
NNG_ESTATE if no corresponding request
was previously received.
Likewise, only one receive operation may be pending at a time.
Any additional concurrent receive operations will result in
Raw mode sockets ignore all these restrictions.
Each context may have at most one outstanding request, and operates independently from the others. 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.)
The rep protocol has no protocol-specific options.
The rep protocol uses a backtrace in the header. This is more fully documented in the req manual.