jiebi/CodeConvo huggingface dataset:
6.14. <ins> A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the control stream to obtain information about the current status of a given track. A TRACK_STATUS message MUST be sent in response to each TRACK_STATUS_REQUEST. 6.15. An endpoint sends a 'TRACK_STATUS' message on the control stream in response to a TRACK_STATUS_REQUEST message. The 'Status Code' field provides additional information about the status of the track.  It MUST hold one of the following values.  Any other value is a malformed message. 0x00: The track is in progress, and subsequent fields contain the highest group and object ID for that track. 0x01: The track does not exist.  Subsequent fields MUST be zero, and any other value is a malformed message. 0x02: The track has not yet begun.  Subsequent fields MUST be zero. Any other value is a malformed message. 0x03: The track has finished, so there is no "live edge."  Subsequent fields contain the highest Group and object ID known. 0x04: The sender is a relay that cannot obtain the current track status from upstream.  Subsequent fields contain the largest group and object ID known. Any other value in the Status Code field is a malformed message. When a relay is subscribed to a track, it can simply return the highest group and object ID it has observed, whether or not that object was cached or completely delivered.  If not subscribed, a relay SHOULD send a TRACK_STATUS_REQUEST upstream to obtain updated information. Alternatively, the relay MAY subscribe to the track to obtain the same information. If a relay cannot or will not do either, it should return its best available information with status code 0x04. The receiver of multiple TRACK_STATUS messages for a track uses the information from the latest arriving message, as they are delivered in order on a single stream. 6.16. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.
To send an Object with "Object Forwarding Preference" = "Track", find the open stream that is associated with the subscription, or open a new one and send the "STREAM_HEADER_TRACK" if needed, then serialize <del> the following object fields. </del> <ins> the following object fields.  The Object Status field is only sent if the Object Payload Length is zero. </ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID
A receiver issues a SUBSCRIBE to a publisher to request a track. <del> 6.4.1. The receiver specifies a start and optional end "Location" for the subscription.  A location value may be an absolute group or object sequence, or it may be a delta relative to the largest group or the largest object in a group. There are 4 modes: None (0x0): The Location is unspecified, Value is not present Absolute (0x1): Value is an absolute sequence RelativePrevious (0x2): Value is a delta from the largest sequence. 0 is the largest sequence, 1 is the largest sequence - 1, and so on. RelativeNext (0x3): Value is a delta from the largest sequence.  0 is the largest sequence + 1, 1 is the largest sequence + 2, and so on. The following table shows an example of how the RelativePrevious and RelativeNext values are used to determine the absolute sequence. 6.4.2. </del> The format of SUBSCRIBE is as follows: Subscribe ID: The subscription identifier that is unique within
Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None. </del> <ins> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </ins> <del> StartObject: The Location of the requested object.  StartObject's Mode MUST NOT be None. </del> <ins> StartObject: The start Object ID, plus 1.  A value of 0 means the latest object.  This field is not present when Start Group is 0. </ins> <del> EndGroup: The last Group requested in the subscription, inclusive. EndGroup's Mode is None for an open-ended subscription. </del> <ins> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended and continues to the end of the track. </ins> <del> EndObject: The last Object requested in the subscription, exclusive.  EndObject's Mode MUST be None if EndGroup's Mode is None.  EndObject's Mode MUST NOT be None if EndGroup's Mode is not None. </del> <ins> EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested.  This field is not present when End Group is 0. </ins> Track Request Parameters: The parameters are defined in <del> On successful subscription, the publisher SHOULD start delivering objects from the group ID and object ID described above. </del> <ins> On successful subscription, the publisher MUST reply with a SUBSCRIBE_OK, allowing the subscriber to determine the start group/ object when not explicitly specified and the publisher SHOULD start delivering objects. </ins> If a publisher cannot satisfy the requested start or end for the subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'.
6.4. <ins> 6.4.1. The subscriber specifies a filter on the subscription to allow the publisher to identify which objects need to be delivered. There are 4 types of filters: Lastest Group (0x1) : Specifies an open-ended subscription with objects from the beginning of the current group. Latest Object (0x2): Specifies an open-ended subscription beginning from the current object of the current group. AbsoluteStart (0x3): Specifies an open-ended subscription with objects beginning from the object identified in the StartGroup and StartObject fields. AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The start and end of the range are inclusive. A filter type other than the above MUST be treated as error. 6.4.2. </ins> A receiver issues a SUBSCRIBE to a publisher to request a track. The format of SUBSCRIBE is as follows:
Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </del> <ins> Filter Type: Identifies the type of filter, which also indicates whether the StartGroup/StartObject and EndGroup/EndObject fields will be present.  See (sub-filter). StartGroup: The start Group ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> <del> StartObject: The start Object ID, plus 1.  A value of 0 means the latest object.  This field is not present when Start Group is 0. </del> <ins> StartObject: The start Object ID within the StartGroup.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> <del> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended and continues to the end of the track. </del> <ins> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. </ins> EndObject: The end Object ID, plus 1.  A value of 0 means the <del> entire group is requested.  This field is not present when End Group is 0. </del> <ins> entire group is requested.  Only present for the "AbsoluteRange" filter type. </ins> Track Request Parameters: The parameters are defined in
StartGroup: The start Group ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. <del> StartObject: The start Object ID, plus 1.  A value of 0 means the entire group is requested.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </del> <ins> StartObject: The start Object ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type.
4.5. <del> Warp encodes the delivery information for each stream via a "HEADERS" frame (headers).  This MUST be at the start of each stream so it is easy for a relay to parse. </del> <ins> Warp encodes the delivery information for a stream via SEGMENT headers (segment). </ins> A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case
5.1. <del> The "HEADERS" message contains information required to deliver, cache, and forward a stream.  This message SHOULD be parsed and obeyed by any Warp relays. </del> <ins> A SEGMENT message contains a single segment associated with a specified track, as well as associated metadata required to deliver, cache, and forward it. The header of the SEGMENT message is as follows: </ins> "id".  An unique identifier for the stream.  This field is optional and MUST be unique if set.
between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency. <del> 5.3. The "APP" message contains arbitrary contents.  This is useful for metadata that would otherwise have to be shoved into the media bitstream. Relays MUST NOT differentiate between streams containing "SEGMENT" and "APP" frames.  The same forwarding and caching behavior applies to both as specified in the"HEADERS" frame. 5.4. </del> <ins> 5.2. </ins> The "GOAWAY" message is sent by the server to force the client to reconnect.  This is useful for server maintenance or reassignments
guarantee that a publisher will not have already sent Objects before the new start Object.  The end Object MUST NOT increase and when it decreases, there is no guarantee that a publisher will not have <del> already sent Objects after the new end Object. </del> <ins> already sent Objects after the new end Object.  A publisher SHOULD close the Session as a 'Protocol Violation' if the SUBSCRIBE_UPDATE violates either rule or if the subscriber specifies a Subscribe ID that does not exist within the Session. </ins> Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to be delivered multiple times.  Like SUBSCRIBE, EndGroup and
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del> <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).
of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given <del> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. </del> <ins> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.  If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription.  The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track
parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. <ins> 6.1.1.2. The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference. If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD always specify the value received from an upstream subscription when there is one, and nothing otherwise.  If an earlier Object arrives later than subsequent Objects, relays can consider the receipt time as that of the next later Object, with the assumption that the Object's data was reordered. If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay that intends to serve multiple subscriptions for the same track. Publishers SHOULD consider whether the entire Object is likely to be delivered before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information. </ins> 6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages
preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. <del> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </del> <ins> An "OBJECT_STREAM" message carries a single object on a stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </ins> An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object".
There are 4 types of filters: Latest Group (0x1) : Specifies an open-ended subscription with <del> objects from the beginning of the current group. </del> <ins> objects from the beginning of the current group.  If no content has been delivered yet, the subscription starts with the first published or received group. </ins> Latest Object (0x2): Specifies an open-ended subscription beginning <del> from the current object of the current group. </del> <ins> from the current object of the current group.  If no content has been delivered yet, the subscription starts with the first published or received group. </ins> AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields.
the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter. <ins> 6.2.2.3. The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID the peer can use when making subscriptions.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </ins> 6.3. The server sends a "GOAWAY" message to initiate session migration
The format of SUBSCRIBE is as follows: <del> Subscribe ID: The subscription identifier that is unique within the session.  "Subscribe ID" is a monotonically increasing variable length integer which MUST not be reused within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR messages. </del> <ins> Subscribe ID: The subscriber specified identifier used to manage a subscription.  "Subscribe ID" is a variable length integer that MUST be unique and monotonically increasing within a session and MUST be less than the session's Maximum Subscribe ID. </ins> Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object),
6.15. <ins> A publisher sends a MAX_SUBSCRIBE_ID message to increase the number of subscriptions a subscriber can create within a session. The Maximum Subscribe Id MUST only increase within a session, and receipt of a MAX_SUBSCRIBE_ID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'. Subscribe ID: The new Maximum Subscribe ID for the session.  If a Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'.  More on Subscribe ID in message- subscribe-req. 6.16. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBEs for tracks within the announced Track Namespace.  The receiver verifies the publisher is authorized
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> "Object Send Order" specified in the stream header. </del> <ins> "Publisher Priority" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".
When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the "Object Send Order" specified in </del> <ins> All objects on the stream have the "Publisher Priority" specified in </ins> the stream header. All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". To send an Object with "Object Forwarding Preference" = "Group", find <del> the open stream that is associated with the subscription, "Group ID" and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </del> <ins> the open stream that is associated with the subscription and "Group ID", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </ins> The Object Status field is only sent if the Object Payload Length is zero.
priority in every stream or datagram header.  As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a property of the Track and the <del> Objects it contains.  In both cases, a lower value indicates a higher </del> <ins> Peeps it contains.  In both cases, a lower value indicates a higher </ins> priority, with 0 being the highest priority. The Subscriber Priority is considered first when selecting a
Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a higher Object <del> Id, regardless of the specified Group Order.  If the priority varies within a Group, higher priority Objects are sent before lower priority Objects. </del> <ins> Id, regardless of the specified Group Order.  If the group contains more than one Peep and the priority varies between these Peeps, higher priority Peeps are sent before lower priority Peeps, and Objects in peeps are sent in increasing Object Id order. </ins> The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used.
priority for the Object priorities. Object Forwarding Preference: An enumeration indicating how a <del> publisher sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. </del> <ins> publisher sends an object.  The preferences are Track, Peep, and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. Peep ID: The object is a member of the indicated peep ID (model- peep) within the group.  This field is omitted if the Object Forwarding Preference is Track or Datagram. </ins> Object Status: As enumeration used to indicate missing objects or mark the end of a group or track.  See object-status below.
7.2. <del> An "OBJECT_STREAM" message carries a single object on a stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object". To send an Object with "Object Forwarding Preference" = "Object", open a stream, serialize object fields below, and terminate the stream. Subscribe ID: Subscription Identifier as defined in message- subscribe-req. Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by Subscribe ID, the subscriber MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. 7.3. </del> An "OBJECT_DATAGRAM" message carries a single object in a datagram. An Object received in an "OBJECT_DATAGRAM" message has an "Object
scenarios where the object size can be larger than maximum datagram size for the session, the Object will be dropped. <del> 7.4. </del> <ins> 7.3. </ins> <del> When multiple objects are sent on a stream, the stream begins with a stream header message and is followed by one or more sets of serialized object fields.  If a stream ends gracefully in the middle of a serialized Object, terminate the session with a Protocol Violation. </del> <ins> When objects are sent on streams, the stream begins with a stream header message and is followed by one or more sets of serialized object fields.  If a stream ends gracefully in the middle of a serialized Object, terminate the session with a Protocol Violation. </ins> <del> A publisher SHOULD NOT open more than one multi-object stream at a time with the same stream header message type and fields. </del> <ins> A publisher SHOULD NOT open more than one stream at a time with the same stream header message type and fields. </ins> TODO: figure out how a relay closes these streams <del> 7.4.1. </del> <ins> 7.3.1. </ins> When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message
A publisher MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object <del> ID is less than or equal to a previously sent Object ID within a given group on that stream. </del> <ins> ID is less than or equal to a previously sent Object ID with the same Group ID. </ins> <del> 7.4.2. </del> <ins> 7.3.2. </ins> <del> When a stream begins with "STREAM_HEADER_GROUP", all objects on the </del> <ins> When a stream begins with "STREAM_HEADER_PEEP", all objects on the </ins> stream belong to the track requested in the Subscribe message <del> identified by "Subscribe ID" and the group indicated by "Group ID". All objects on the stream have the "Publisher Priority" specified in the stream header. </del> <ins> identified by "Subscribe ID" and the peep indicated by 'Group ID' and "Peep ID". </ins> <del> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". </del> <ins> All Objects received on a stream opened with "STREAM_HEADER_PEEP" have an "Object Forwarding Preference" = "Peep". </ins> <del> To send an Object with "Object Forwarding Preference" = "Group", find the open stream that is associated with the subscription and "Group ID", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </del> <ins> To send an Object with "Object Forwarding Preference" = "Peep", find the open stream that is associated with the subscription, "Group ID" and "Peep ID", or open a new one and send the "STREAM_HEADER_PEEP". Then serialize the following fields. </ins> The Object Status field is only sent if the Object Payload Length is zero.
OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track <del> and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT payload content for making forwarding decisions and MUST only depend on the fields, such as priority order and other metadata properties in the OBJECT message header.  Unless determined by congestion response, Relays MUST forward the OBJECT message to the matching subscribers. </del> <ins> and find the active subscribers for that track.  Relays MUST forward OBJECT messages to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout. </ins> 5.3.