Draft broadcast channel abstraction

[angbrav]

WIP

Rendered

Broadcast channel abstraction.

[angbrav]

Great work @angbrav , it's nice and clean! I think we could also need to define a callback interface similar to the one in ICS26. That way, application modules can interact with the core broadcast channel through callbacks

Shouldn't we add it to ICS26 directly?

[angbrav]

Thank your for starting this spec, @angbrav! I left a couple of comments and I have some questions:

Thanks for the questions!

• Since we don't have a 4-way handshake, doesn't seem like it will be possible to do versions negotiation? Would that be a problem at some point?

I do not think it is a problem. This is a one-to-many communication primitive, I do not think there can be a negotiation. In this case, the broadcaster should just pick a version.

• If the broadcaster closes the channel, would the idea be that an event will be emitted as result and the relayer can pick that up and then close the channel on the subscribers as well?

I could do that. What do you think @AdityaSripal?

• If a broadcaster opens a channel and subscribers subscribe to it and receive packet, what happens when a new subscriber joins later on? If I understand it correctly, the subscriber will initialize the next sequence recv to 1, but the broadcaster might already have sent several packets and is using a sequence number > 1...

This is a good question. I was thinking that the relayer should relay all packets with sequence number >= 1

[AdityaSripal]

Shouldn't we add it to ICS26 directly?

Yes but add it in a separate document since not all modules will have to implement this interface

I could do that. What do you think?

Yes I think we should have a simple closing handshake

If a broadcaster opens a channel and subscribers subscribe to it and receive packet, what happens when a new subscriber joins later on? If I understand it correctly, the subscriber will initialize the next sequence recv to 1, but the broadcaster might already have sent several packets and is using a sequence number > 1...

This is a good question. In the unordered case we don't need to worry about this. In the ORDERED case, I could see it working in a couple ways. Either we enforce all the sequences to be sent. Or we can initialize the subscriber with a starting sequence s > 1, then all packets p >= s must be sent to it. I'm in favor of the second approach

[crodriguezvega]

This is a good question. In the unordered case we don't need to worry about this. In the ORDERED case, I could see it working in a couple ways. Either we enforce all the sequences to be sent. Or we can initialize the subscriber with a starting sequence s > 1, then all packets p >= s must be sent to it. I'm in favor of the second approach

Yes, I agree with the second approach; I think it makes more sense.

Another question: will it be possible to have incentivized broadcast channels? If so, how will that work?

[AdityaSripal]

Another question: will it be possible to have incentivized broadcast channels? If so, how will that work?

Yes, this would be done on the subscriber side. This is out of scope for this spec