-
Notifications
You must be signed in to change notification settings - Fork 382
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
1-n broadcast #544
Comments
Difference between "UDP multicast" (no knowledge of receiver) and "receiver-known" broadcast. The former should not require handshakes, the latter will. Subscriptions mechanisms will likely require the latter (known receivers). |
Maybe best for "IBC 1.1". |
However, we should ensure that this can be added in a backwards-compatible way. |
Microtick is also interested in 1 to N channels. |
I believe the former can be specified as a backward-compatible way
we need to define a way to abstract a set of channels into a single channel in this case, but we can reuse the logic. For the latter, we need to define a new channel type, with single-sided opening/closing and time-based cleanup. |
By the former, you mean "receiver-known" broadcast, right, since the sender designates the receiver set? Even with "receiver-known" broadcast I think we should allow the receiver set to change after the channel has been opened. |
Should work both on ordered & unordered channels.
This will need to alter the handshakes.
The text was updated successfully, but these errors were encountered: