StreamLD WebSocket Replication Binding

Draft Community Group Report,

This version:
https://openfaster.org/streamld/binding-websocket
Issue Tracking:
GitHub
Editor:
OpenFASTER Editors

Abstract

Defines StreamLD’s server-to-server replication binding over WebSockets — the transport a downstream server uses to mirror an upstream stream in full, in order, with explicit resumption. Part of the StreamLD module.

← Back to the StreamLD module index

1. Overview

Unlike the SSE binding (StreamLD SSE Binding), which serves a single browser client, the WebSocket replication binding is intended for one server mirroring another server’s stream in full. There is no browser-platform reconnection help available on this transport, so resumption is handled entirely in-protocol.

2. Join and backlog

A replicating server opens a WebSocket connection and sends a join request carrying a `streamld:SubscriptionRequest` (see StreamLD Core, The Event Envelope). The upstream server responds with either every already-buffered `streamld:ReplicationFrame` with `streamld:cursor` greater than the requested `streamld:after` value, in ascending cursor order, or a `streamld:GapSignal`, per the same rule as StreamLD Core, Gap handling, if the requested cursor is not resolvable.

3. Live frames

After a successful join, the upstream server pushes one `streamld:ReplicationFrame` per subsequent append, in cursor order. A replicating server MUST persist the highest cursor it has durably stored, so that a reconnect after a network interruption can resume from that persisted cursor rather than the beginning of the stream.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119