search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
84 stars 22 forks source link

Announces with same name in reconnect #227

Closed fluffy closed 1 month ago

fluffy commented 1 year ago

When the relays received an ANNOUNCE with exact same name as previous ANNOUNCE, what happens?

Options seem to be replace previous ANNOUNCE data or return an error.

This is related to https://github.com/moq-wg/moq-transport/issues/225 and https://github.com/moq-wg/moq-transport/issues/204

Discussion to follow in thread

fluffy commented 1 year ago

One of use cases we should think about is a client that crashes and reconnects.

afrind commented 1 year ago

As an individual,

The crash (or disconnect) use case is compelling for "the most recent one wins". Are there applications where that policy would break something?

fluffy commented 1 year ago

I agree with Alan that "most recent" overwrites any earlier ones is best path forward.

suhasHere commented 1 year ago

+1 on most recent overwrites. this is what we do atleast today and it works fine to the amount we have tested.

kixelated commented 1 year ago

Going with the most recent ANNOUNCE works for me, so long as the relay MUST send an ANNOUNCE_ERROR and UNSUBSCRIBE for any matching subscriptions to the original session. Otherwise we'll introduce zombie announcements and subscriptions.

fluffy commented 1 year ago

WFM

suhasHere commented 1 year ago

Going with the most recent ANNOUNCE works for me, so long as the relay MUST send an ANNOUNCE_ERROR and UNSUBSCRIBE for any matching subscriptions to the original session. Otherwise we'll introduce zombie announcements and subscriptions.

I Dont think existing subscriptions needs to be terminated.

Let say the case where, A publisher disconnects due to getting into an elevator for a moment and sends announce on reconnect, sending out protocol messages to cancel the subscriptions on the second announce is too noisy.

afrind commented 1 year ago

As an individual:

I don't think we need to force unsubscribe everyone if the relay successfully resubscribes to the new ANNOUNCE.

I think Luke is suggesting that the relay unsubscribe on the session that issued the old ANNOUNCE?

kixelated commented 1 year ago

As an individual:

I don't think we need to force unsubscribe everyone if the relay successfully resubscribes to the new ANNOUNCE.

I think Luke is suggesting that the relay unsubscribe on the session that issued the old ANNOUNCE?

Yeah exactly. The upstream subscription is reissued to the new connection, but any downstream subscriptions can be maintained by updating a lookup table. I can elaborate if this isn't clear; the glue between "upstream" and "downstream" subscriptions can be confusing.

suhasHere commented 1 year ago

Got it. Makes sense. Agree all the downstream subscriptions can stay intact for the announced namespace

ianswett commented 1 month ago

Closed by #525