- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Sat, 13 Jan 2018 14:49:31 +0100
- To: public-webrtc@w3.org
(I forgot to CC public-webrtc@w3.org, so I'm forwarding missing messages of this thread for the sake of completeness.) -------- Forwarded Message -------- Subject: Re: Towards a new charter for the WebRTC Working Group Date: Fri, 12 Jan 2018 01:58:01 +0100 From: Lennart Grahl <lennart.grahl@gmail.com> To: Iñaki Baz Castillo <ibc@aliax.net> CC: Lorenzo Miniero <lorenzo@meetecho.com>, T H Panton <thp@westhawk.co.uk>, Peter Thatcher <pthatcher@google.com>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Martin Thomson <martin.thomson@gmail.com>, Dominique Hazael-Massieux <dom@w3.org> On 12.01.2018 00:22, Iñaki Baz Castillo wrote: > On 11 January 2018 at 13:31, Lennart Grahl <lennart.grahl@gmail.com> wrote: >> It took me a while to see this, too but it clicked when I basically >> ported a lot of code from RAWRTC to Firefox. I'd be happy to pull out >> RAWRTC's data channel implementation and make it possible to use this >> outside of RAWRTC itself. RAWRTC is a good candidate for this as it has >> very few dependencies. I guess this would be particularly interesting >> for smaller projects that want data channels such as janus-gateway. >> Please reach out to me if you're interested. > > Is it C/C++ and does not assume multi-threading? C. No multi-threading. > I cannot use usrsctplib because it uses different threads internally, > mandating the app (that integrates it) to also be multi-thread. So I > cannot use it. > A good C library should not run a separate thread by itself to just > run a timer. Instead, provide a mechanism to tell the app when to pull > data from the lib (even openssl allows that). I use usrsctp-neat which has a function I need to call every 20ms instead of a timer thread. But I remember that there was at least a bug with a thread idling - we'll need to ping them if this is still the case and an issue for you (it didn't really matter to me at the time of writing and I had other stuff on my mind). The features from usrsctp-neat I'm using will also be merged back into usrsctp at some point (this is already in progress, see https://github.com/sctplab/usrsctp/pull/189). > Also, does your lib manage UDP/TCP ports by itself? or does it expose > a proper I/O API + events? I don't want/need a datachannel library > that manages ports, ICE or even DTLS. I already do that so just need a > layer on top of what I've already that. Yeah, of course RAWRTC does ICE, STUN, TURN and DTLS right now. But if we pull out the data channel implementation only, we'll need to define some API that roughly includes passing inbound data, a callback function for outbound data, some timer functions that needs to be called in a specific interval and possibly some other functionality that includes setting the MTU for SCTP, retrieving some information from the DTLS transport (such as whether the role is client or server), etc. This way, we're able to use it in RAWRTC but you are able to use it in your implementation, too. Cheers Lennart
Received on Saturday, 13 January 2018 13:49:55 UTC