- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Sun, 12 Feb 2012 11:41:29 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
On Feb 11, 2012, at 4:43 AM, Harald Alvestrand wrote: > On 02/10/2012 03:57 PM, Cullen Jennings wrote: >>> > Open >>> > ==== >>> > * Should the API be uni- or bi-directional? >> I will argue very strongly for bi-directional. It makes is much easier to to protocol where you send a request and expect a response to that request. It's what programmer expect. There pretty much no reason not to. It depends on the semantic of the channel. In SCTP the only semantic is that you can provide "in-sequence delivery" only within a single stream. But you don't tie request and responses together by the streams. It must be made clear what a developer has to provide and can expect... >> > Just to make this clear if it was not: > > When I say "unidirectional", I mean that each channel is unidirectional: You send on a channel, you receive on a channel. Just because you need N channels for sending doesn't mean that you need to have N channels for receiving. Makes sense to me... > The overall SCTP association is definitely bidirectional. > > I suspect there's a class of apps out there where it will feel natural to open up 10 incoming channels and 1 outgoing channel (or vice versa), each of which uses resources in our SCTP control blocks. I don't see a reason why the API should force us to instantiate the 9 SCTP channels we won't use. It would be good to provide a hint to the stack how many channels might be used at the time the SCTP association is established. The number can be increased later, but it takes an RTT to set them up and the peer can deny it... Best regards Michael > > (not that the cost is high. I won't cry if we decide to do bidirectional only). > > Harald > > > >
Received on Monday, 13 February 2012 10:38:18 UTC