-
Notifications
You must be signed in to change notification settings - Fork 20
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
'Expires' in SUBSCRIBE_OK makes it unclear what the final group and object will be #390
Comments
I'd like to get rid of |
I agree that a subscriber can deal with this field, but I don't know what purpose it serves for the publisher/relay? It's different from an idle connection timeout, because assuming there is data flowing for the subscription, it would never go idle. Unlike QUIC, I don't see value in having a 'silent close' for subscriptions, because typically we expect subscriptions to have data flowing at a somewhat regular interval. Also, there's no guarantee that the subscription will last until the expiry time, it can always end early with SUBSCRIBE_FIN or SUBSCRIBE_RESET. |
Based on last week's conversation, the Expires field doesn't change the state of the subscription by itself, a publisher would still have to send a FIN or RESET to close it. It's still unclear as to what a subscriber should do with it. There was a fair amount of discussion around refreshing one's authorization. It's unclear if that would be done with a SUBSCRIBE_UPDATE or something similar or via UNSUBSCRIBE/SUBSCRIBE? |
And add a new SUBSCRIBE_DONE status code. Fixes part of #390, but it's still unclear how one might refresh a subscription without interruption.
Would the solution to this be when the relay expires a subscription, it sends a control message ? This might all become clearer once we figure out re authentication but at a high level, I want some way that the relays can clean up state on a time line that is under relay control particularly when poorly implemented clients make subscriptions. |
I think this was resolved by #406 -
|
Subscriptions always end with either SUBSCRIBE_FIN or SUBSCRIBE_RESET, except when they Expire and then no control message is sent. This complicates the state machine and adds another case to handle.
The subscriber needs to start a timer or something similar to know when the subscription will end, and it doesn't get to know the final group or object ID.
The text was updated successfully, but these errors were encountered: