nng_rep(7)

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

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.)

COPYRIGHT

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

+ + + diff --git a/man/v0.0.0/nng_req.html b/man/v0.0.0/nng_req.html new file mode 100644 index 00000000..489632ea --- /dev/null +++ b/man/v0.0.0/nng_req.html @@ -0,0 +1,693 @@ +--- +version: 0.0.0 +layout: default +--- + + + + + + + + +nng_req(7) + + + + + + + +

SYNOPSIS

#include <nng/protocol/reqrep0/req.h>
+
+int nng_req0_open(nng_socket *s);

DESCRIPTION

The nng_req 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. +

+ + + + + +

+ +	+Because requests are resent, it is important that they be idempotent +to ensure predictable and repeatable behavior even in the face of duplicated +requests, which can occur (for example if a reply message is lost for +some reason.) +

The requester generally only has one outstanding request at a time unless +in "raw" mode (via NNG_OPT_RAW), and it will generally attempt to spread +work requests to different peer repliers.

+ + + + + +

+ +	+This property, when combined with a device can +help provide a degree of load-balancing. +

The nng_req protocol is the requester side, and the +nng_rep(7) protocol is the replier side.

Socket Operations

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

Requests may be canceled by sending a different request. This will +cause the requester to discard any reply from the earlier request, +but it will not stop a replier +from processing a request it has already received or terminate a request +that has already been placed on the wire.

Attempts to receive 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_REQ_RESENDTIME: +
This read/write option is a duration (32-bit unsigned integer) representing +a relative number of milliseconds. +When a new request is started, a timer of this duration is also started. +If no reply is received before this timer expires, then the request will +be resent. (Requests are also automatically resent if the peer to whom +the original request was sent disconnects, or if a peer becomes available +while the requester is waiting for an available peer.)
+
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_req 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.)

COPYRIGHT

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

+ + + diff --git a/man/v0.0.0/nng_respondent.html b/man/v0.0.0/nng_respondent.html new file mode 100644 index 00000000..0e846b82 --- /dev/null +++ b/man/v0.0.0/nng_respondent.html @@ -0,0 +1,645 @@ +--- +version: 0.0.0 +layout: default +--- + + + + + + + + +nng_respondent(7) + + + + + + + +

SYNOPSIS

#include <nng/protocol/survey0/respondent.h>
+
+int nng_respondent0_open(nng_socket *s);

DESCRIPTION

The nng_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 after +not obliged to). The survey itself is a timed event, so that responses +received after the survey has finished are discarded.

+ + + + + +

+ +	+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 nng_respondent protocol is the respondent side, and the +nng_surveyor(7) protocol is the surveyor side.

Socket Operations

The nng_respondent0_open() call creates a respondent socket. This socket +may be used to receive messages, and then to send replies. Generally +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.

Protocol Versions

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.)

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_respondent 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 survey, and when replying removes +elements to obtain the next hop information. The survey ID is at the +end of this header and is inserted into the header as its first element +by the originating surveyor. (Survey IDs are distinguished from hops by +having their high order bit set to one.)

COPYRIGHT

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

+ + + diff --git a/man/v0.0.0/nng_strerror.html b/man/v0.0.0/nng_strerror.html index b011ec13..ca09a0a1 100644 --- a/man/v0.0.0/nng_strerror.html +++ b/man/v0.0.0/nng_strerror.html @@ -570,14 +570,6 @@ by a NUL byte.

AUTHORS

Garrett D’Amore

AUTHORS

Garrett D’Amore

SYNOPSIS

#include <nng/protocol/survey0/survey.h>
+
+int nng_surveyor0_open(nng_socket *s);

DESCRIPTION

The nng_surveyor 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 after +not obliged to). The survey itself is a timed event, so that responses +received after the survey has finished are discarded.

+ + + + + +

+ +	+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 nng_surveyor protocol is the surveyor side, and the +nng_respondent(7) protocol is the respondent side.

Socket Operations

The nng_surveyor0_open() call creates a respondent socket. This socket +may be used to send messages (surveys), and then to receive replies. Generally +a reply can only be received after sending a survey. Generally a surveyor +can expect to receive at most one reply from each responder. (Messages +can be duplicated in some topologies, so there is no guarantee of this.)

Attempts to receive on a socket with no outstanding survey will result +in NNG_ESTATE. If the survey times out while the surveyor is waiting +for replies, then the result will be NNG_ETIMEDOUT.

Only one survey can be outstanding at a time; sending another survey will +cancel the prior one, and any responses from respondents from the prior +survey that arrive after this will be discarded.

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

Protocol Versions

Protocol Options

The following protocol-specific options are available.

NNG_OPT_SURVEYOR_SURVEYTIME: +
This read/write option is a duration (32-bit unsigned integer) representing +a relative number of milliseconds that following surveys will last. +When a new survey is started, a timer of this duration is also started. +Any responses arriving this time will be discarded. Attempts to receive +after the timer expires with no other surveys started will result in +NNG_ESTATE. Attempts to receive when this timer expires will result in +NNG_ETIMEDOUT.
+
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_surveyor 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 survey, and when replying removes +elements to obtain the next hop information. The survey ID is at the +end of this header and is inserted into the header as its first element +by the originating surveyor. (Survey IDs are distinguished from hops by +having their high order bit set to one.)

COPYRIGHT

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

+ + + diff --git a/man/v0.0.0/nng_tcp.html b/man/v0.0.0/nng_tcp.html index a6de2083..26c17488 100644 --- a/man/v0.0.0/nng_tcp.html +++ b/man/v0.0.0/nng_tcp.html @@ -656,14 +656,6 @@ options.^{[
-AUTHORS
-
-
-Garrett D’Amore
-
-
-}

AUTHORS

Garrett D’Amore

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

nng_rep(7) Manual Page

NAME

SYNOPSIS

DESCRIPTION

Socket Operations

Protocol Versions

Protocol Options

Protocol Headers

SEE ALSO

COPYRIGHT

nng_req(7) Manual Page

NAME

SYNOPSIS

DESCRIPTION

Socket Operations

Protocol Versions

Protocol Options

Protocol Headers

SEE ALSO

COPYRIGHT

nng_respondent(7) Manual Page

NAME

SYNOPSIS

DESCRIPTION

Socket Operations

Protocol Versions

Protocol Options

Protocol Headers

SEE ALSO

COPYRIGHT

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO

nng_surveyor(7) Manual Page

NAME

SYNOPSIS

DESCRIPTION

Socket Operations

Protocol Versions

Protocol Options

Protocol Headers

SEE ALSO

COPYRIGHT

AUTHORS

SEE ALSO

AUTHORS

SEE ALSO