Protocol state machine targets

[SeanTAllen]

Lori handles TCP connection lifecycle and I/O, but protocol logic — parsing, framing, state transitions — is left entirely to the application. The examples show this: each one reimplements its own ad-hoc state tracking with raw byte handling. For anything beyond a toy echo server, this gets complex fast.

The idea: Lori should be able to drive protocol state machines. Someone writing an HTTP server or Redis client should be able to layer a protocol implementation on top of Lori rather than building the full actor + byte-wrangling machinery from scratch each time.

The best way to figure out what abstraction Lori needs is to build several protocols on top of it and see what patterns emerge. Different protocols stress different aspects of a state machine driver — strict command ordering, mode switches, bidirectional messaging, protocol upgrades, framing strategies. Building a few of these will reveal the common scaffolding that Lori should provide.

Target protocols

1. HTTP server

Request/response with headers and body framing (Content-Length and chunked Transfer-Encoding). Keep-alive means the state machine cycles back to "awaiting request" after each response. The parsing side (request line, headers, body) is well-specified and exercises line-based + length-delimited framing.

2. HTTP client

Same wire format as the server but from the other side — sending requests, parsing responses. Exercises pipelining (multiple requests in flight on one connection) and handling response bodies that may be chunked, length-delimited, or connection-close terminated.

3. Redis (RESP protocol)

Very simple wire format (bulk strings, arrays, integers, errors), so the framing layer is nearly trivial compared to HTTP. The interesting aspect is the mode switch: normal mode is request/response, but SUBSCRIBE flips the connection into pub/sub mode where the server pushes messages and most commands become invalid. Also supports pipelining (multiple commands in flight), which tests how the state machine tracks outstanding requests.

4. SMTP

Classic strict-ordering state machine: CONNECT → server greeting → EHLO → (optional AUTH) → MAIL FROM → RCPT TO → DATA → dot-terminated body → QUIT. Each state has a small set of valid commands, and the server's response code determines the next valid transition. Also has a mode switch: command mode (line-based) vs data mode (dot-stuffed body). Multi-line responses (250-continuation lines) add parsing complexity. Good testbed because the state machine is rigid and well-documented in RFCs.

5. WebSocket

Starts as an HTTP/1.1 upgrade handshake, then switches to a binary-framed bidirectional protocol. Exercises protocol upgrade (analogous to STARTTLS), framed messages with opcodes, control frames (ping/pong/close) interleaved with data frames, and client-side masking. The bidirectional nature means both sides can initiate messages at any time — fundamentally different from request/response. Has a natural dependency on HTTP (the handshake), so it also exercises layering one protocol on another.

What these cover together

Pattern	Protocols
Request/response	HTTP, Redis
Strict sequential state machine	SMTP
Mode switch	Redis (normal → pub/sub), SMTP (command → data)
Bidirectional messaging	WebSocket
Protocol upgrade / layering	WebSocket (over HTTP)
Line-based framing	HTTP headers, SMTP
Length-delimited framing	HTTP body, Redis bulk strings
Binary framing	WebSocket
Pipelining	HTTP client, Redis

Building across these should surface the right abstractions for Lori to provide as protocol state machine infrastructure.