TimEvens
commented
1 year ago +1 for changing SUBSCRIBE_REPLY to include a pointer to where you are joining into the stream. In this case, group_id and object_id.
IMHO, the subscription SHOULD always start at the last complete group_id/object_id. An object_id that is still in flight is okay to send, but that would be for object_id + 1. The start hopefully would be at complete (no more offsets pending) group_id/object_id**.
Starting at the last complete group/object id imposes an expectation on the relay to ensure they have that in the buffers, which best_before might need to be overridden if set to short.
In a real time conference, participants are likely to "subscribe" to a named "stream", such as "Alice's camera number 5, high res". That real time stream will consist of a series of groups, each containing multiple objects. I think that the draft should describe a subscribe transaction, not just a subscribe "message". Something like:
Getting the "start point" in the response message will allow the client to do a clean start. If the first object that it receives is "15/6" or 16/1", then the client knows that something is missing, and if appropriate the client may wait a bit for the missing data to arrive before processing data. On the other hand, if the first object received is 15/5, the client can start processing immediately.
This will also provide a neat API for "repair" or "reconnect" functionalities:
In the example, the client lost a previous connection after receiving group 15, object 4, It selects a different relay, and proceeds with a new subscription. It tell the relay that it would like transmission to start just after the previous point, i.e., at group 15 object 5. If the relay can server that, it will. But it may also be too late, the old frames are not in the cache anymore, so the relay picks a new start point and sends it to the client.