v2 Plans about sctp HOT 5 OPEN

I see (or hope) not much re-architing required here. sctp.Stream is already looks like net.Conn. We have two goroutines: writeLoop and readLoop, which wouldn't change. Read operation is already blocking, so it is Stream.WriteSCTP() (<-- I'd remove this method btw..) and underlying call into Association needs to be modified. I'd say we can just use Association's mutex to block the write operation (Association.sendPayloadData()). A challenge I can see from top of my head is because we have many streams competing over the shared Association, we'd need to figure out how to control the deadlines (e.g. SetDeadline, SetWriteDeadline). We'd need a small/short-lived timer routine for each blocking call...

This is my quick thought (I may be wrong). I think it is good idea for you to just go ahead try it out ;)

from sctp.

I'll give it a go once some of my paid work lets up :D

from sctp.

Also, for what it's worth, I don't think we're in any rush here, so no pressure to respond ASAP to this.

from sctp.

I'd recommend to focus on just blocking writes for v2.
I am aware there are other desired API change such as Listen, Dial (to align with the standard SCTP API) but I think these are "nice to have" features imo and we can do it later. Also, yes RACK/TLP does not require API change.

Many users have been suffering from the async write and the blocking write is the most wanted feature atm. The streamlined goal with v2 make it more achievable to put it into pion/webrtc v4. (getting rid of pendingQueue out of the way for the future enhancement is also nice)

from sctp.

That's fine with me. Do you have any vision for what you'd re-architect to achieve blocking writes? I could "just" go down a proof of concept route to achieve and see what changes fall out. What do you think?

from sctp.