-
Notifications
You must be signed in to change notification settings - Fork 35
Joining Fetch #638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Joining Fetch #638
Changes from 38 commits
619a6ec
4525f9d
8e1e9ca
7f19b5e
921f4c4
c285647
8fa9be8
e1093ad
1522ab7
0a00c36
e0e649e
07e93ce
d01b841
dbc9f9a
204437e
578b567
6dae36d
9fa2429
a50b040
6c0790f
eb20e67
7d4a99d
450b4d7
7db23b5
86ec7ff
094d800
5b1ec66
9cbde3c
e5a2868
d7e8648
f408e38
46f2124
6076f68
df48071
a70455e
411d42e
c3442de
cc7de8d
648dbc4
801fb4b
d9e2731
3bc9c52
3a45e97
913c9d7
5945077
e3fe1a2
2529140
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -1514,6 +1514,27 @@ objects within a track. The publisher responding to a FETCH is responsible for r | |||||
all available Objects. If there are gaps between Objects, the publisher omits them from the | ||||||
fetch response. All omitted objects have status Object Does Not Exist. | ||||||
|
||||||
**Fetch Types** | ||||||
|
||||||
There are two types of Fetch messages: | ||||||
|
||||||
Standalone Fetch (0x1) : A Fetch of Objects performed independently of any Subscribe. | ||||||
|
||||||
Joining Fetch (0x2) : A Fetch joined together with a Subscribe. A Joining Fetch | ||||||
shares the same Subscribe ID as an already-sent Subscribe. A publisher receiving a | ||||||
Joining Fetch uses properties of the associated Subscribe to determine the | ||||||
Track Namespace, Track, StartGroup, StartObject, EndGroup, and EndObject for the | ||||||
Joining Fetch such that it is contiguous with the associated Subscribe and begins | ||||||
Preceding Group Offset prior. | ||||||
|
||||||
A Subscriber can use a Joining Fetch to, for example, fill a playback buffer with a | ||||||
certain number of groups prior to the live edge of a track. | ||||||
|
||||||
A Joining Fetch is only permitted when the associated Subscribe has the Filter | ||||||
Type Latest Object. | ||||||
|
||||||
A Fetch Type other than the above MUST be treated as an error. | ||||||
|
||||||
A publisher responds to a FETCH request with either a FETCH_OK or a FETCH_ERROR | ||||||
message. If it responds with FETCH_OK, the publisher creates a new unidirectional | ||||||
stream that is used to send the Objects. A relay MAY start sending objects immediately | ||||||
|
@@ -1533,29 +1554,33 @@ FETCH Message { | |||||
Type (i) = 0x16, | ||||||
Length (i), | ||||||
Subscribe ID (i), | ||||||
Track Namespace (tuple), | ||||||
Track Name Length (i), | ||||||
Track Name (..), | ||||||
Subscriber Priority (8), | ||||||
Group Order (8), | ||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
StartGroup (i), | ||||||
StartObject (i), | ||||||
EndGroup (i), | ||||||
EndObject (i), | ||||||
Fetch Type (i), | ||||||
[Track Namespace (tuple), | ||||||
Track Name Length (i), | ||||||
Track Name (..), | ||||||
StartGroup (i), | ||||||
StartObject (i), | ||||||
EndGroup (i), | ||||||
EndObject (i),] | ||||||
[Preceding Group Offset (i),] | ||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
Number of Parameters (i), | ||||||
Parameters (..) ... | ||||||
} | ||||||
~~~ | ||||||
{: #moq-transport-fetch-format title="MOQT FETCH Message"} | ||||||
|
||||||
Fields common to all Fetch Types: | ||||||
|
||||||
* Subscribe ID: The Subscribe ID identifies a given fetch request. Subscribe ID | ||||||
is a variable length integer that MUST be unique and monotonically increasing | ||||||
within a session. | ||||||
|
||||||
* Track Namespace: Identifies the namespace of the track as defined in | ||||||
({{track-name}}). | ||||||
|
||||||
* Track Name: Identifies the track name as defined in ({{track-name}}). | ||||||
within a session. For a Standalone Fetch a new Subscribe ID MUST be used. For | ||||||
a Joining Fetch, the Subscribe ID MUST correspond to a Subscribe which has already | ||||||
englishm marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
been sent. If a publisher receives a Joining Fetch with a Subscribe ID that does | ||||||
not correspond to an existing Subscribe, it MUST respond with a Fetch Error. | ||||||
Though they share an ID, cancelling or updating the subscription has no impact | ||||||
on the Fetch and vice versa. | ||||||
|
||||||
* Subscriber Priority: Specifies the priority of a fetch request relative to | ||||||
other subscriptions or fetches in the same session. Lower numbers get higher | ||||||
|
@@ -1566,6 +1591,17 @@ Ascending (0x1) or Descending (0x2) order by group. See {{priorities}}. | |||||
A value of 0x0 indicates the original publisher's Group Order SHOULD be | ||||||
used. Values larger than 0x2 are a protocol error. | ||||||
|
||||||
* Fetch Type: Identifies the type of Fetch, whether joining or standalone. | ||||||
|
||||||
* Parameters: The parameters are defined in {{version-specific-params}}. | ||||||
|
||||||
Fields present only for Standalone Fetch (0x1): | ||||||
|
||||||
* Track Namespace: Identifies the namespace of the track as defined in | ||||||
({{track-name}}). | ||||||
|
||||||
* Track Name: Identifies the track name as defined in ({{track-name}}). | ||||||
|
||||||
* StartGroup: The start Group ID. | ||||||
|
||||||
* StartObject: The start Object ID. | ||||||
|
@@ -1575,8 +1611,11 @@ used. Values larger than 0x2 are a protocol error. | |||||
* EndObject: The end Object ID, plus 1. A value of 0 means the entire group is | ||||||
requested. | ||||||
|
||||||
* Parameters: The parameters are defined in {{version-specific-params}}. | ||||||
Field present only for Joining Fetch (0x2): | ||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
* Preceding Group Offset: The group offset for the Fetch prior and relative | ||||||
to the StartGroup of the corresponding Subscribe. A value of 0 indicates | ||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
the current Group. | ||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
Objects that are not yet published will not be retrieved by a FETCH. | ||||||
The latest available Object is indicated in the FETCH_OK, and is the last | ||||||
|
@@ -1590,9 +1629,37 @@ subgroup ID is not used for ordering. | |||||
If StartGroup/StartObject is greater than the latest published Object group, | ||||||
the publisher MUST return FETCH_ERROR with error code 'No Objects'. | ||||||
|
||||||
A publisher MUST send fetched groups in group order, either ascending or | ||||||
descending. Within each group, objects are sent in Object ID order; | ||||||
subgroup ID is not used for ordering. | ||||||
### Calculating the Range of a Joining Fetch | ||||||
|
||||||
A publisher which receives a Fetch message with a Fetch Type of 0x2 treats it | ||||||
as a Fetch with a range dynamically determined by the Preceding Group Offset | ||||||
field and field values derived from the corresponding SUBSCRIBE message | ||||||
(hereafter "the Subscribe"). | ||||||
|
||||||
The following values are used: | ||||||
|
||||||
* Resolved Subscribe Start Group: the Largest Group ID of the associated Subscribe. | ||||||
* Resolved Subscribe Start Object: the Largest Object ID of the associated Subscribe. | ||||||
|
||||||
The Resolved Subscribe Start values for a Joining Fetch MUST correspond to the | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: I don't think you need a MUST here. This is just explaining how the mechanism works and why.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is actually a requirement, but I see how it's easy to read it as just descriptive. The important part is the "within the same session" which precludes responding to Subscribe at relay, but forwarding the Joining Fetch and having it resolved against a different Subscribe at an upstream relay. We don't necessarily want to entirely preclude forwarding upstream, but it's important that the Joining Fetch be resolved within the same session as the associated Subscribe so that this join point is consistent. This text originated after the 2024-12-18 weekly interim where the main issue raised (mainly by Cullen and Alan, if I recall correctly) was a desire to clarify requirements relating to forwarding behavior. My initial stab at text for that was in this commit: 9dfceaf followed by some discussion tightening it up here: #638 (comment) If this is too subtle, we could expand it a bit again or rephrase it to make the requirement more clear, but the MUST here is intentional. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think everything in this document is in the context of a single session, except for some advice on relays, so I thought that aspect was a bit out of place. For example, SUBSCRIBE_UPDATE and SUBSCRIBE_CANCEL don't clarify that you're altering a subscription within the session because it's implied. |
||||||
referenced Subscribe within the same session so that the ranges of Objects covered | ||||||
by the Fetch and Subscribe are contiguous and non-overlapping. | ||||||
If no Objects have been published for the track, so the SUBSCRIBE_OK has a | ||||||
ContentExists value of 0, the publisher MUST respond to the Joining Fetch with a | ||||||
FETCH_ERROR. | ||||||
|
||||||
The publisher receiving a Joining Fetch computes the fetch range as follows: | ||||||
|
||||||
englishm marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
* Fetch StartGroup: Resolved Subscribe Start Group - Preceding Group Offset | ||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
* Fetch StartObject: 0 | ||||||
|
||||||
If Resolved Subscribe Start Object is 0: | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/Resolved Subscribe Start Object is 0/ Subscribe FilterType is LatestGroup There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's not the only case here. This can also be true if the StartObject field of a Subscribe with Filter Type of AbsoluteStart or AbsoluteRange is 0. This is an example of why I'd prefer to retain that above section defining "Resolved Subscribe..." values rather than just referring directly to the Subscribe section's definitions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am fine with having the section on Resolved subscribes , but seems bit incorrect to compute those absolute values given those are filters and may not map to the exact values that we mention here There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As above, I'm thinking of this in terms of computing an absolute value for the requested range so we can delineate which portion would be provided by a Fetch (subject to whatever limitations a standalone Fetch is subject to) and which portion would be provided by a Subscribe (subject to whatever limitations a Subscribe is subject to). |
||||||
* Fetch EndGroup: Resolved Subscribe Start Group - 1 | ||||||
* Fetch EndObject: 0 (all objects in the group) | ||||||
|
||||||
Else, if Resolved Subscribe Start Object is 1 or more: | ||||||
* Fetch EndGroup: Resolved Subscribe Start Group | ||||||
* Fetch EndObject: Resolved Subscribe Start Object | ||||||
|
||||||
## FETCH_CANCEL {#message-fetch-cancel} | ||||||
|
||||||
|
Uh oh!
There was an error while loading. Please reload this page.