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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
nng_ws(7)
=========
:doctype: manpage
:manmanual: nng
:mansource: nng
:icons: font
:source-highlighter: pygments
:copyright: Copyright 2018 Staysail Systems, Inc. <info@staysail.tech> \
Copyright 2018 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_ws - WebSocket transport for nng
SYNOPSIS
--------
[source,c]
----------
#include <nng/transport/websocket/ws.h>
int nng_ws_register(void);
int nng_wss_register(void);
----------
DESCRIPTION
-----------
The _nng_ws_ transport provides communication support between
_nng_ sockets across a TCP/IP network using
https://tools.ietf.org/html/rfc6455[WebSockets]. Both IPv4 and IPv6
are supported when the underlying platform also supports it.
The protocol details are documented in
http://nanomsg.org/rfcs/sp-websocket-v1.html[WebSocket Mapping for Scalability Protocols].
Registration
~~~~~~~~~~~~
Depending upon how the library was built, it may be necessary to
register the transport by calling `nng_ws_register`. This function
returns zero on success, or an nng error value if the transport
cannot be initialized for any reason.
If TLS support is enabled in the library, secure WebSockets (over TLS v1.2)
can be used as well, but the secure transport may have to be registered using
the `nng_wss_register` function. (Note that this function will not be
present if TLS support was not enabled in the library.)
URI Format
~~~~~~~~~~
This transport uses URIs using the scheme `ws://`, followed by
an IP address or hostname, optionally followed by a colon and an
TCP port number, optionally followed by a path. (If no port number
is specified then port 80 is assumed. If no path is specified then
a path of `/` is assumed.)
For example, the URI `ws://localhost/app/pubsub` would use
port 80 on localhost, with the path `/app/pubsub`.
Secure WebSockets (if enabled) use the scheme `wss://`, and the default
TCP port number of 443. Otherwise the format is the same as for regular
WebSockets.
When specifying IPv6 addresses, the address must be enclosed in
square brackets (`[]`) to avoid confusion with the final colon
separating the port.
For example, the same path and port on the IPv6 loopback address (`::1`)
would be specified as `ws://[::1]/app/pubsub`.
NOTE: When using symbolic names, the name is resolved when the
name is first used. _nng_ won't become aware of changes in the
name resolution until restart,
usually.footnote:[This is a bug and will likely be fixed in the future.]
NOTE: The value specified as the host, if any, will also be used
in the `Host:` HTTP header during HTTP negotiation.
To listen to all ports on the system, the host name may be elided from
the URL on the listener. This will wind up listening to all interfaces
on the system, with possible caveats for IPv4 and IPv6 depending on what
the underlying system supports. (On most modern systems it will map to the
special IPv6 address `::`, and both IPv4 and IPv6 connections will be
permitted, with IPv4 addresses mapped to IPv6 addresses.)
Socket Address
~~~~~~~~~~~~~~
When using an `nng_sockaddr` structure, the actual structure is either
of type `nng_sockaddr_in` (for IPv4) or `nng_sockaddr_in6` (for IPv6).
These are `struct` types with the following definitions:
[source,c]
--------
#define NNG_AF_INET 3 <1>
#define NNG_AF_INET6 4
#define NNG_MAXADDRLEN 128
typedef struct {
// ... <2>
uint16_t sa_family; // must be NNG_AF_INET
uint16_t sa_port; // TCP port number
uint32_t sa_addr;
// ...
} nng_sockaddr_in;
typedef struct {
// ... <2>
uint16_t sa_family; // must be NNG_AF_INET6
uint16_t sa_port; // TCP port number
uint8_t sa_addr[16];
// ...
} nng_sockaddr_in6;
--------
<1> The values of these macros may change, so applications
should avoid depending upon their values and instead use them symbolically.
<2> Other members may be present, but only those listed here
are suitable for application use.
The `sa_family` member will have the value `NNG_AF_INET` or `NNG_AF_INET6`.
The `sa_port` and `sa_addr` are the TCP port number and address, both in
network byte order (most significant byte is first).
Transport Options
~~~~~~~~~~~~~~~~~
The following transport options are available. Note that
setting these must be done before the transport is started.
`NNG_OPT_WS_REQUEST_HEADERS`::
This value is a string, consisting of multiple lines terminated
by CRLF sequences, that can be used to add further headers to the
HTTP request sent when connecting. This option can be set on dialers,
and retrieved from pipes.
`NNG_OPT_WS_RESPONSE_HEADERS`::
This value is a string, consisting of multiple lines terminated
by CRLF sequences, that can be used to add furthe headers to the
HTTP response sent when connecting. This option can be set on listeners,
and retrieved from pipes.
`NNG_OPT_WSS_TLS_CONFIG`::
This option is used on an endpoint to access the underlying TLS
configuration object. The value is of type `nng_tls_config *`.
Note that attempts to set this object may fail on a listener if
the server is already running. Furthermore, attempts to modify the
configuration object will fail if it is already in active use.
This object is only available for `wss://` endpoints.
`NNG_OPT_WSS_TLS_CA_FILE`::
This is a write-only option used to load certificates associated
associated private key from a file. The value is a C string
containing the path name of the file. The file itself must contain
https://tools.ietf.org/html/rfc7468[PEM] format objects for one or more
X.509 certificates. It may also contain certificate revocation list (CRL)
objects well. Note that attempts to call this will fail if the
configuration associated with the underlying endpoint
is already in use. This option is only available for `wss://` endpoints.
`NNG_OPT_WSS_TLS_CERT_KEY_FILE`::
This is a write-only option used to load the local certificate and
associated private key from a file. The value is a C string
containing the path name of the file. The file itself must contain PEM
format objects for the X.509 certificate and private key. Multiple
certificates may be listed in the file, to provide a validation chain,
with the leaf certificate listed first, and subsequent certificates listed
afterwards. Note that attempts to call this will fail if the
configuration associated with the underlying endpoint
is already in use. This option is only available for `wss://` endpoints.
The private key must not be encrypted. (Use the `NNG_OPT_WSS_TLS_CONFIG`
option to get the underlying TLS configuration if more advanced
configuration is needed.)
// We should also look at a hook mechanism for listeners. Probably this could
// look like NNG_OPT_WS_LISTEN_HOOK_FUNC which would take a function pointer
// along the lines of int hook(void *, char *req_headers, char **res_headers),
// and NNG_OPT_LISTEN_HOOK_ARG that passes the void * passed in as first arg.
// Alternatively we can uplevel the HTTP API and pass the actual HTTP objects.
SEE ALSO
--------
<<nng#,nng(7)>>,
<<nng_tls_config_alloc#,nng_tls_config_alloc(3)>>
COPYRIGHT
---------
Copyright 2018 mailto:info@staysail.tech[Staysail Systems, Inc.] +
Copyright 2018 mailto:info@capitar.com[Capitar IT Group BV]
This document is supplied under the terms of the
https://opensource.org/licenses/MIT[MIT License].
|
