Use WebRTC data channel instead of Websockets about channels

[caniko]

Do you know anything about aiortc? Can I use that in django/django-channels and make a django app with P2P video chat + screensharing? I am a bit out of my depth, any tip would help.

[andrewgodwin]

I'm open to adding support for WebRTC as well - the design of channels is explicitly about supporting any kind of bidirectional protocol - but it's definitely not going to replace WebSockets as the one we write first and encourage for tutorials; they're much more ubiqutous, simpler to understand and communicate to developers, there's plenty of code and test suites in multiple languages for handling them, and the challenges in scaling up the serving of them is well-understood.

I'm going to close this mostly because if I left an issue open for every protocol we might be able to support (you could theoretically also serve FTP, DNS, SMTP and more over Channels, though those are less useful), it would get messy. Rest assured, if there's people interested in making an interface server for WebRTC happen, it's not too hard to add that into the stack mixed in with other protocols.

[mitar]

Does your concept of channels also support "any bidirectional protocol with backpressure"? Because for any serious scaling to happen you do need backpressure. Otherwise you have only messaging, not really channels. Websockets do not support backpressure, WebRTC does.

[andrewgodwin]

Flow control/backpressure is something the interface servers would have to deal with; the channel protocol itself is simplistic on purpose and only does whole message delivery. I'm sure some kind of signalling mechanism could be done to communicate current buffer sizes to the application, but if you need that level of control over communication then channels is likely not for you.

[mitar]

Yes, but Websockets does not expose the underlying TCP/SCTP congestion. While WebRTC does through the bufferedamountlow event.

What I would like to see is that the API would expose this to Django. And then maybe on Websockets that would never be triggered, but if the underlying protocol is WebRTC it would.

[andrewgodwin]

It would be entirely possible to send bufferedamountlow as a channel event to prompt more sending of data - that fits within the abstraction (basically, channels is event-driven by things other than the application code). It's still too complex and specialised to make part of the core project, though; definitely suited to a third-party contribution by someone who has the interest and resources to maintain it.

[mitar]

But that event should also get exposed to the application code. So that the code can detect that the messages are not getting through and can back-off. It is not enough just to do that on the transport level.

[andrewgodwin]

Then WebRTC isn't going to work over the abstraction. The design here is much more about streaming bits of data to lots of clients rather than lots of data, and WebSocket is the thing people are asking for and which has the reasonable API; if we change the abstraction we lose a lot of the scalability (it's limited for some very good reasons, which you can read about in the docs)

[caniko]

Still no WebRTC support? :(

[andrewgodwin]

No, it's not a goal of the Channels project and we don't have the spare people to work on it, sorry! If you'd like it the best thing to do is to gather an interested group and get to work.

[andrewgodwin]

I'm afraid I don't know anything about it, sorry. I've never ventured into that protocol at all.

[harry-dev98]

Sir if you start workiing on integrating WEBRTC support to django channels.. i'd love to work on that with you or anyone else working...