The WebSocket transport uses the framing protocol specified in RFC 6455 to transport messages. The initial handshake is done using HTTP headers, with the Sec-Websocket-Protocol header set to the SP protocol used by the server. For example, a REQ client will send rep.sp.nanomsg.org.
Each SP message is transported in a single WebSocket frame, with no additional data or headers applied. By default this library sends and expects to receive binary frames.
When calling either nn_bind() or nn_connect(), omitting the port defaults to the RFC 6455 default port 80 for HTTP. For example, ws://127.0.0.1 is equivalent to ws://127.0.0.1:80
When calling nn_connect(), the URI may also optionally include the path to a resource and/or query parameters.
Example 1. Path and query parameters
s1 = nn_socket (AF_SP, NN_PAIR); nn_connect (s1, "ws://example.com/path?query=value");
This implementation includes the full path and any query parameters in the HTTP handshake when establishing connections with nn_connect(). This information is not available via the nanomsg API afterwards, however.
Likewise, this implementation does not examine or use either any path or query parameters that may be supplied to nn_bind(), as it only binds to the TCP port. This implementation acts as a limited HTTP server that offers SP over WebSocket at all URIs for the given TCP address.
Applications, however, should not depend on this behavior; intervening infrastructure may proxy, filter or route based on URI, and other implementations of the SP over WebSocket protocol may offer other HTTP services at the same TCP port, utilizing the path, query parameters, or both to determine the service to be used.
This option may also be specified as control data when when sending a message with nn_sendmsg().
nn_bind (s1, "ws://*:5555"); nn_connect (s2, "ws://myserver:5555");