You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/concept/layer/moq-lite.md
+8-3Lines changed: 8 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,9 @@ Here's a list of currently supported ALPNs:
51
51
See the Compatibility section below for more details about `moq-transport` support.
52
52
53
53
Once the QUIC or WebTransport connection is established, there is a minimal MoQ handshake.
54
-
The `SETUP` message is primarily used to negotiate extensions, then you're off to the races!
54
+
Each endpoint sends a single `SETUP` message advertising its capabilities (for example whether it can probe the available bitrate), then you're off to the races.
55
+
The two `SETUP` messages are independent, so neither side waits for the other before getting started.
56
+
Transports that don't carry a request URI (native QUIC, or qmux over TCP/TLS) also use `SETUP` to carry the path the client wants to reach.
55
57
56
58
### Announcements
57
59
@@ -67,6 +69,9 @@ The [moq-relay clustering](/bin/relay/cluster) feature actually uses this to dis
67
69
The peer first replies with the set of broadcasts that are currently live, then streams updates as they change.
68
70
This initial set is a discrete batch: the latest draft reports how many entries to expect up front, so a freshly connected session can wait until that snapshot has fully arrived before listing what's available, rather than racing the gossip.
69
71
72
+
Each broadcast also carries an **epoch** identifying its instance.
73
+
When the same broadcast is announced over multiple routes (or republished after going away), the epoch lets everyone converge on the newest instance instead of picking arbitrarily.
74
+
70
75
### Subscriptions
71
76
72
77
All data transfers are initiated by subscriptions.
@@ -102,8 +107,8 @@ Each Subscription consists of a few properties:
102
107
-**Group Order**: The order in which groups are delivered. Defaults to descending; higher IDs are delivered first.
103
108
-**Group Timeout**: The maximum duration to keep old groups in cache/transit. Defaults to 30 seconds.
104
109
105
-
The publisher also caps how long it retains old groups via a per-track**cache**age, announced in `SUBSCRIBE_OK`so relays re-serve with the same window.
106
-
A subscriber's Group Timeout can only be smaller than this cache age, since a group can't be waited for longer than it's kept around.
110
+
The publisher also keeps old groups around for a best-effort**cache**window so relays and late subscribers can still fetch them.
111
+
This is a local hint rather than a guarantee carried on the wire, and a subscriber's Group Timeout is bounded by it: a group can't be waited for longer than it's actually kept around.
107
112
108
113
By utilizing these properties, you can choose how your application behaves during congestion.
109
114
For example, consider a conference room with Alice and Bob:
0 commit comments