Do publishers need to remember that a subgroup received STOP_SENDING?

[afrind]

Because subscribers can join a subscription midway through a group, my fan-out logic will always open a new stream if an object is published on a subgroup that doesn't have a stream yet.

But what happens when the subscriber sends STOP_SENDING? After RESET_STREAM, does the publisher need to hold state that it should never send another object in this subgroup to this subscriber?

[yekuiwang]

In that case, the subscriber has indicated that it is no longer interested in receiving that subgroup, then after acknowledging by sending RESET_STREAM (or RESET_STREAM_AT), the publisher does need to honor "the agreement" and should never send another object in this subgroup to this subscriber, unless the subscriber indicates its interest on this subgroup again.

[afrind]

Just to use a concrete example, let's assume the following:

S->P: SUBSCRIBE
P->S: Subgroup 0, object 0
S->P: STOP_SENDING sg=0
P->S: RESET_STREAM sg-0
...
S->P: SUBSCRIBE_UPDATE Fwd=0
...
S->P: SUBSCRIBE_UPDATE Fwd=1
P: Publishes sg=0, object 1

Does sending a SUBSCRIBE_UPDATE with fwd=1 constitute "subscriber indicating interest in this subgroup again"?

[yekuiwang]

Interesting example.

Usually, I thought SG0 would be the most important SG, thus typically the subscriber either sends STOP_SENDING for one or more highest SGs or it sends UNSUBSCRIBE.

Therefore, probably the example would make more sense when changing sg0 to sgN (with N > 0, say 7). With that, I would assume if the subscriber sends STOP_SENDING sg=7, it jus says that it is not interested in sg7, but still interested in the lower SGs. Then sending updates of Fwd should only indicate its preference of pausing or resuming receiving of interested SGs.

On the other hand, how can a subscriber indicate that it changed its mind and now is again interested in SG7? Currently there is no way of doing that I guess?

[afrind]

Yes sg=7 is a better example.

On the other hand, how can a subscriber indicate that it changed its mind and now is again interested in SG7? Currently there is no way of doing that I guess?

Unsubscribe and re-subscribe is the only way maybe.

[yekuiwang]

Unsubscribe and re-subscribe is the only way maybe.

Hmm, and that is probably OK for such a corner use case.

[kixelated]

STOP_SENDING is slightly better than SUBSCRIBE_UPDATE alone because the subscriber will immediately free up flow control, rather than wait for a RESET_STREAM in response to the SUBSCRIBE_UPDATE.

I don't see any benefit to transmitting the tail of a reset subgroup. The subscriber obviously doesn't want it, and even if it did, it would need to issue a FETCH to populate the gap.

[afrind]

Discussed on 12/1 Interim:

• Sending STOP_SENDING is like adding an implicit (subgroup != current subgroup ID) filter -- the publisher won't send any more.
• Reset streams for other reasons sometimes work like this (eg: Delivery Timeout)
• Resetting streams because of a subgroup discontinuity (caused by a filter or other weirdness) does not work like this -- eg: if I subscribe with a filter like Object ID != 7, I should get 0-6+RESET, then 8-10+FIN.