WebSocket Mapping for Scalability Protocols

Standard WebSocket handshake is done following RFC 6455. The Sec-WebSocket-Protocol field MUST be set in the client's HTTP request to match the protocol used by the WebSocket server. Accordingly, the following values should be used. pair.sp.nanomsg.org (NN_PAIR client and server) req.sp.nanomsg.org (NN_REQ server, NN_REP client) rep.sp.nanomsg.org (NN_REP server, NN_REQ client) pub.sp.nanomsg.org (NN_PUB server, NN_SUB client) sub.sp.nanomsg.org (NN_SUB server, NN_PUB client) surveyor.sp.nanomsg.org (NN_SURVEYOR server, NN_RESPONDENT client) respondent.sp.nanomsg.org (NN_RESPONDENT server, NN_SURVEYOR client) push.sp.nanomsg.org (NN_PUSH server, NN_PULL client) pull.sp.nanomsg.org (NN_PULL server, NN_PUSH client) bus.sp.nanomsg.org (NN_BUS client and server) If the server supports the requested SP protocol as indicated by the Sec-WebSocket-Protocol header, then it MUST respond with the same Sec-WebSocket-Protocol value sent by the client. If the server does support the requested SP protocol, then it MUST fail the WebSocket connection using the Close code of 1002, as specified in RFC 6455. For example, an NN_REQ client socket, connecting to an NN_REP server, will send the value rep.sp.nanomsg.org in the Sec-WebSocket-Protocol field. The NN_REP socket on the server would then include the same rep.sp.nanomsg.org in its response.

SP message maps directly to WebSocket message. The message can be fragmented as needed. Frame boundaries are ignored by the SP layer. When possible, binary frames SHOULD be used in preference to text frames. If text frames are in use, then SP message payloads MUST be comprised of legal UTF-8 text only.