summaryrefslogtreecommitdiff
path: root/docs/nng_surveyor.adoc
blob: 5b121cf055114894f660b5e27cf6cc1b56ee3d46 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
nng_surveyor(7)
===============
:doctype: manpage
:manmanual: nng
:mansource: nng
:icons: font
:source-highlighter: pygments
:copyright: Copyright 2017 Garrett D'Amore <garrett@damore.org> \
            Copyright 2017 Capitar IT Group BV <info@capitar.com> \
            This software is supplied under the terms of the MIT License, a \
            copy of which should be located in the distribution where this \
            file was obtained (LICENSE.txt).  A copy of the license may also \
            be found online at https://opensource.org/licenses/MIT.

NAME
----
nng_surveyor - surveyor protocol

SYNOPSIS
--------

[source,c]
----------
#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.

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 _nng_surveyor_ protocol is the surveyor side, and the
<<nng_respondent.adoc#,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
~~~~~~~~~~~~~~~~~

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
http://nanomsg.org[nanomsg], but was not released in any production
version.)

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

// TODO: Insert reference to RFC.

    
SEE ALSO
--------
<<nng.adoc#,nng(7)>>
<<nng_respondent.adoc#,nng_respondent(7)>>

COPYRIGHT
---------

Copyright 2017 mailto:garrett@damore.org[Garrett D'Amore] +
Copyright 2017 mailto:info@capitar.com[Capitar IT Group BV]

This document is supplied under the terms of the
https://opensource.org/licenses/LICENSE.txt[MIT License].