nanomsg next generation NNG  
Home GitHub Documentation

This documentation is for version 0.0.0 of nng, but the latest released version is v1.10.0. see the documentation for v1.10.0 for the most up-to-date information.
nng_rep(7)

SYNOPSIS

#include <nng/protocol/reqrep0/rep.h>

int nng_rep0_open(nng_socket *s);

DESCRIPTION

The nng_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 nng_rep protocol is the replier side, and the nng_req(7) protocol is the requester side.

Socket Operations

The nng_rep0_open() call creates a requester socket. This socket may be used to receive messages (requests), and then to send replies. Generally a reply can only be sent after receiving a request. (Attempts to receive a message will result in NNG_ESTATE if there is no outstanding request.)

Attempts to send on a socket with no outstanding requests will result in NNG_ESTATE.

Raw mode sockets (set with NNG_OPT_RAW) ignore all these restrictions.

Protocol Versions

Only version 0 of this protocol is supported. (At the time of writing, no other versions of this protocol have been defined.)

Protocol Options

The following protocol-specific options are available.

NNG_OPT_MAXTTL

Maximum time-to-live. This option is an integer value between 0 and 255, inclusive, and is the maximum number of "hops" that a message may pass through until it is discarded. The default value is 8. A value of 0 may be used to disable the loop protection, allowing an infinite number of hops.

Protocol Headers

The nng_rep protocol uses a backtrace in the header. This form uses an array of 32-bit big-endian identifiers, where the first element in the array identifies the local peer identifier to which the message will next be sent. This is a hop-by-hop header where each element in a path adds routing information to the end when sending a request, and when replying removes elements to obtain the next hop information. The request ID is at the end of this header and is inserted into the header as its first element by the originating surveyor. (Request IDs are distinguished from hops by having their high order bit set to one. They are generated automatically and randomly when a request is first issued.)

SEE ALSO

Copyright 2017 Garrett D’Amore
Copyright 2017 Capitar IT Group BV

This document is supplied under the terms of the MIT License.

© 2025 Garrett D'Amore and contributors.
nanomsg™ and nng™ are trademarks of Garrett D'Amore.