Module track_locations 

How far each track’s objects have reached, and where each one ended.

Two rules, and the drafts that state them are not the same set. Drafts 08 through 13 make an end-of-track object’s Group and Object ID a protocol error when they name a place the track has already passed, which takes a record of where the track has reached; drafts 07 and 14 through 20 have no such sentence, draft-07 having no ordering condition on the status at all and draft-14 having replaced it with a prohibition on the publisher. Drafts 12 through 20 make an object past where an end-of-track object put the end a Malformed Track, which takes a record of that place instead.

So the module is compiled wherever either rule is, and which of its two entry points a draft calls is what says which rule it states. The overlap is drafts 12 and 13, where both hold. How far each track’s objects have reached, for the drafts that make an end-of-track object’s placement a protocol error.

Six drafts state it. Draft-11 Section 9.1.1.1 gives the form that drafts 12 and 13 repeat word for word: Object Status 0x4 “Indicates end of Track. GroupID is either the largest group produced in this track and the ObjectID is one greater than the largest object produced in that group, or GroupID is one greater than the largest group produced in this track and the ObjectID is zero. This status also indicates the last group has ended. An object with this status that has a Group ID less than any other GroupID, or an ObjectID less than or equal to the largest in the specified group, is a protocol error, and the receiver MUST terminate the session.”

Drafts 08, 09 and 10 spell the same prohibition against a status 0x4 that means “end of Track and Group”, and carry a second status beside it — 0x5, “end of Track” — whose condition is one notch stricter: “An object with this status that has a Group ID less than or equal to any other Group ID, or an Object ID other than zero, is a protocol error, and the receiver MUST terminate the session.” Draft-11 merged the two statuses and kept the looser condition, which is why one record answers both.

This module holds only the observation. What each draft does about it is its own close table’s business, as it is for every other rule broken on a data stream.

Two numbers per track, and that is not a shortcut

“The largest object produced in that group” reads like a record of every group a track has carried, which for a live track is unbounded. It is not needed, and the reason is the other half of the same sentence.

The Group ID condition says an end-of-track object may not name a group behind any the track has carried. So by the time the Object ID condition is read, “the specified group” is either the largest group the track has carried or one beyond it — and a group beyond it has carried no objects, so there is no largest in it to be at or behind. Every group below the largest is unreachable by the question. Two numbers answer it: the largest Group ID seen, and the largest Object ID seen in that group, which resets whenever a larger group arrives.

Only Normal objects are produced objects

An object with a status is a statement about objects rather than one of them, and two of the statuses name an ID one past the end on purpose. Status 0x3, End of Group, has an “ObjectId … one greater that the largest object produced in the group”; status 0x4 has an Object ID one greater again. So a record that counted an End of Group object as produced would raise the largest by one and then refuse the very End of Track object the draft defines — the rule would fire on a conforming track. Only status Normal is written down.

Why the key is the track and not the alias

The same reason crate::forwarding_preference gives: an alias is free again the moment its subscription ends and may then name a different track, so a record kept against the alias would measure the second track’s end-of-track object against the first track’s groups. The alias is resolved through the endpoint’s binding table before anything is written down.

Which objects reach this

Objects a subscriber receives, on subgroup streams and in datagrams. The sentence names the receiver — “the receiver MUST terminate the session” — which is what separates this from the forwarding-preference rule beside it: that one names the Original Publisher, so its writers are gated too, and this one does not.

A second rule, and a third number

Drafts 12 through 20 carry a Malformed Track condition this record is the right place for as well. Draft-12 Section 2.5: “An Object is received on a Track whose Group and Object ID are larger than the final Object in the Track. The final Object in a Track is the Object with Status END_OF_TRACK or the last Object sent in a FETCH whose response indicated End of Track.” Drafts 13 through 17 carry it word for word; drafts 18, 19 and 20 drop the two words “on a Track” and change nothing else.

It is the mirror of the rule above rather than a widening of it. That one asks whether an end-of-track object is behind what the track has carried, and ends the session over it. This one asks whether an ordinary object is past where the track ended, and withdraws from the track. Two rules, two answers, and the two numbers above answer neither of them for the other: a third is kept, the location the end-of-track object named, written down once that object has been judged.

Larger is the drafts’ own comparison and not a reading of the words. Every draft that carries the condition carries a Location Structure section with it, and that section settles the ordering outright — draft-12 Section 1.3.1 and draft-19 Section 1.4.2 give one Location as below another in the same words: “A.Group < B.Group || (A.Group == B.Group && A.Object < B.Object)”. Lexicographic, and worth naming because the field-by-field reading the sentence also admits would let an object in a later group with a smaller Object ID escape, which is the plainest case of the fault there is.

The FETCH half of the definition is out of reach on this path, and is not quietly folded into the other half. A fetch’s objects arrive on a stream that opens by naming a Request ID and never a Track Alias, so nothing measuring objects here knows which track they belong to. What is written down is the END_OF_TRACK half, and a track whose end was only ever announced by a fetch response has no final object recorded to be past.

Structs

ObjectLocation

The Group and Object an object names.

TrackLocations

How far each track’s objects have reached, so far.

TrackObjects

One track’s record, held by whatever is reading that track’s objects.

TrackRecord 🔒

One track and how far its objects have reached.

Enums

EndOfTrackForm

Which of the two conditions an end-of-track status carries.

EndOfTrackPlacement

Why an end-of-track object is not where the track ended.

ObjectRole

What an Object Status makes of an object here.

TrackFault

What went wrong with an object measured against its track’s record.