- 
                Notifications
    
You must be signed in to change notification settings  - Fork 39
 
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 41 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 by specifying | ||||||
| the Subscribe ID of an active subscription. A publisher receiving a | ||||||
| Joining Fetch uses properties of the associated Subscribe to determine the | ||||||
| Track Namespace, Track, StartGroup, StartObject, EndGroup, and EndObject such that | ||||||
| it is contiguous with the associated Subscribe. The Joining Fetch begins the | ||||||
| Preceding Group Offset prior to the associated subscription. | ||||||
| 
     | 
||||||
| 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 0x1 or 0x2 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,29 @@ 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), | ||||||
| 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),] | ||||||
| [Joining Subscribe ID (i), | ||||||
| Preceding Group Offset (i),] | ||||||
| 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. | ||||||
| 
     | 
||||||
| * 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 +1587,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 +1607,15 @@ 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.
               
              
                Outdated
          
            Show resolved
            Hide resolved
         | 
||||||
| 
     | 
||||||
| * Joining Subscribe ID: The Subscribe ID of the existing subscription to be | ||||||
| joined. 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. | ||||||
| 
     | 
||||||
| * Preceding Group Offset: The group offset for the Fetch prior and relative | ||||||
| to the Current Group of the corresponding Subscribe. A value of 0 indicates | ||||||
| the Fetch starts at the beginning of the Current Group. | ||||||
| 
     | 
||||||
| 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 | ||||||
                
       | 
||||||
| The Resolved Subscribe Start values for a Joining Fetch MUST correspond to the | |
| The Resolved Subscribe Start values for a Joining Fetch correspond to the | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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.
        
          
              
                  englishm marked this conversation as resolved.
              
          
            Show resolved
            Hide resolved
        
              
          
              
                  ianswett marked this conversation as resolved.
              
              
                Outdated
          
            Show resolved
            Hide resolved
        
              
          
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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 comment
The 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 comment
The 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).
Uh oh!
There was an error while loading. Please reload this page.