websocket.h File Reference

Minimal RFC 6455 WebSocket server, enough to serve LineWebSocketServer's protocol. More...

#include <cstdint>
#include <cstring>
#include <string>
#include <vector>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#include "line/util/error.h"

Include dependency graph for websocket.h:

Go to the source code of this file.

Classes
class	line::ws::WsError
	Transport-level failure: the port is taken, the peer vanished, a bad frame. More...
class	line::ws::Server
	A listening socket; one connection is served at a time. More...

Namespaces
namespace	line
namespace	line::ws

Detailed Description

Minimal RFC 6455 WebSocket server, enough to serve LineWebSocketServer's protocol.

The JAR runs java -jar jline.jar -p <port> as a solve server: a client opens a WebSocket, sends ONE text message whose first line is the CSV argument list and whose remainder is the model document, and receives the CLI's output as one text message before the connection closes. This is the same protocol, spoken directly over a POSIX socket.

NO DEPENDENCY, for http.h's reason: java-websocket is a link-time obligation in the JAR and Boost.Beast would pull Asio and its thread requirements into every binary in this tree, to speak a framing that fits in two hundred lines. What is implemented is exactly what the protocol uses – the opening handshake, masked client text frames of any length, continuation frames, ping/pong and close.

NO TLS, as http.h has none: the server binds a port for a local client, and a caller who needs an authenticated channel must front it with a proxy rather than believe this one provides it.

ONE CONNECTION AT A TIME, deliberately. A solve is CPU-bound and the JAR's server serves one message per connection and closes; accepting concurrently would let two solves contend for the same cores and report timings neither would produce alone.

Definition in file websocket.h.