Skip to main content

Module websocket

netget::server

Module websocket 

Source
Expand description

WebSocket (RFC 6455) server with LLM-controlled frames.

§Why the handshake is hand-written and the framing is not

tokio-tungstenite’s accept_hdr_async takes a synchronous callback to inspect the request and shape the 101 response. Choosing a subprotocol is the one genuinely interesting decision in this protocol and it needs a model call, which is async. So the HTTP Upgrade half of RFC 6455 §4.2 is done here by hand — read the request head, validate it, emit websocket_handshake, and only then write the 101 with the Sec-WebSocket-Accept derived from the client’s Sec-WebSocket-Key — and the already upgraded socket is handed to WebSocketStream::from_partially_read for everything below §5: frame parsing, the mandatory client-to-server mask check, continuation-frame reassembly, automatic pongs, and the closing handshake.

§What the LLM decides

  • whether an upgrade is accepted at all, and with which Sec-WebSocket-Protocol
  • every text and binary frame the server sends, including unprompted ones
  • the close code and reason

§What the server does without asking

  • rejects a malformed or non-WebSocket request with an HTTP error (no model call: there is no decision, the request is simply not a WebSocket upgrade)
  • answers pings with pongs, echoes the peer’s close frame, reassembles fragments
  • refuses the upgrade when the model answers with neither accept_websocket nor reject_websocket — silence must not read as consent

§No storage

actions::WS_CONNECTIONS holds live socket handles so the model can address a recipient by id. Nothing is retained past a disconnect: no message log, no rooms, no subscriptions.

Modules§

actions
WebSocket (RFC 6455) server actions, events and metadata.
deflate
RFC 7692 permessage-deflate, as a byte stream beneath tungstenite.

Structs§

RequestHead
The request line and headers of an HTTP/1.1 request, parsed far enough to decide whether it is a WebSocket upgrade.
UpgradeRejection
Why an HTTP request is not an acceptable WebSocket upgrade.
WebSocketServer

Constants§

DEFAULT_PERMESSAGE_DEFLATE
Whether the server accepts a client’s RFC 7692 permessage-deflate offer. On by default: browsers offer it on every connection, and accepting is what a WebSocket server does. The permessage_deflate startup parameter turns it off.
IDLE_TIMEOUT
How long an upgraded connection may go without a single frame from the peer.
MAX_SIZE_LIMIT

Functions§

build_accept_response
Build the 101 Switching Protocols response for a validated handshake.
build_error_response
Build a plain HTTP error response used to refuse an upgrade.
parse_request_head
Parse an HTTP/1.1 request head (everything before the terminating blank line).
validate_upgrade
Check a parsed request against RFC 6455 §4.2.1 and return the client’s Sec-WebSocket-Key when it is a valid upgrade.