A WebSocket is a protocol for two-way message exchange over a persistent connection. In a quant application, a client can subscribe to quotes and receive updates as the service sends them, rather than repeatedly asking for the latest value. Receiving messages still leaves a separate question: is the local market-data state complete and current?
What the connection provides
RFC 6455 establishes the channel with an HTTP upgrade. Either endpoint can then send text or binary messages, possibly split across frames.
wss:// adds TLS. The application defines its JSON quotes, subscriptions and instrument identifiers. RFC 6455, sections 1.2–1.3 and 10.6.TCP supplies a reliable, ordered byte stream within a connection. Its transport sequence numbers are distinct from any sequence field in a quote payload. This does not create a durable event log or continuity across a broken connection. RFC 9293, section 2.2.
Ping/Pong checks responsiveness; it does not establish quote freshness. After abnormal closure, RFC 6455 recommends reconnection backoff. Reconnecting does not itself replay missed market events: recovery requires the feed's application contract. RFC 6455, sections 5.5.2–5.5.3 and 7.2.3.
A gap is an application decision
Consider an offline, fictional quote feed for one instrument. Prices are USD per unit. Its deliberately simple contract requires each update to have the next consecutive integer sequence number. A verified snapshot supplies a complete current quote and the sequence through which that state is valid. These are assumptions of this example: real feeds can use different numbering scopes, filtered channels or recovery rules.
Start from a verified state at sequence 1, price 100. The next update received has sequence 3, price 102. Under this contract, sequence 2 is missing. Mark the local state invalid for use as a current quote and stop applying updates until recovery; accepting 102 would hide the continuity failure.
This is not evidence that TCP silently skipped part of its byte stream. The fixture does not specify a cause: an upstream omission, application processing failure or interrupted session would need investigation.
An ordered connection and a complete application history are different guarantees. This fictional protocol requires consecutive sequence numbers; a snapshot restores state, not missing events.
Now stipulate a verified snapshot at sequence 3, price 102. It establishes a new current-state baseline. The next update, sequence 4, price 101, is consecutive and can be applied. The resulting state is 4 / 101. Sequence 2's event remains unknown: the snapshot cannot reconstruct a missing trade, return observation or event-time path.
Check continuity before using the quote
This Python example operates only on the fictional tuples above. It opens no connection and does not test a WebSocket library. Payload types, instrument identity and price validity are assumed checked before these tuples reach the continuity check.
None marks state that must be recovered.def apply_quote(state: tuple[int, int] | None,
quote: tuple[int, int]) -> tuple[int, int]:
"""Apply one update under the toy consecutive-sequence contract."""
if state is None:
raise ValueError("verified snapshot required")
expected = state[0] + 1
if quote[0] != expected:
raise ValueError(f"gap: expected {expected}, got {quote[0]}")
return quote
state = (1, 100) # verified starting snapshot
try:
state = apply_quote(state, (3, 102))
except ValueError as exc:
state = None # do not expose the old quote as current
print(exc)
# gap: expected 2, got 3
state = (3, 102) # stipulated verified recovery snapshot
state = apply_quote(state, (4, 101))
print("state:", *state)
# state: 4 101A production client must follow its vendor's snapshot-and-update alignment rules, including updates arriving during recovery. It also needs separate policies for duplicate or older messages, authentication, stale data and processing overload. A growing queue can make an intact stream economically obsolete; a sequence check alone cannot establish timeliness.
For the earlier decoding step, APIs teaches offline JSON parsing and quote-field validation. The public page is a preview; the full lesson requires membership. Its HTTP examples provide preparation for payload checks, rather than a WebSocket client implementation.
Sources
- IETF RFC 6455, The WebSocket Protocol: sections 1.2–1.3 (handshake and messages), 5.4–5.6 (framing and control), 7.2.3 (reconnection backoff), and 10.5–10.7 (authentication, TLS and validation).
- IETF RFC 9293, section 2.2: TCP's ordered byte-stream service. The fictional application sequence rule and recovery snapshots above are not requirements of either RFC.