Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use WebRTC data channel instead of Websockets #38

Closed
mitar opened this issue Dec 12, 2015 · 12 comments
Closed

Use WebRTC data channel instead of Websockets #38

mitar opened this issue Dec 12, 2015 · 12 comments

Comments

@mitar
Copy link

mitar commented Dec 12, 2015

I think we should make a paradigm shift and move to use WebRTC instead of Websockets. This allows many interesting properties:

  • connections can be based on SCTP
  • have multi-path routing
  • you can have data packets which are reliable or unreliable
  • you can even have backpressure support (imagine that you could push back on Meteor publish because client cannot handle observes as quickly as server is pushing)

There is a great open source project already available which provides both client server suppor: https://github.com/feross/simple-peer

Some interesting links to read:

@andrewgodwin
Copy link
Member

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
Copy link
Author

mitar commented Dec 12, 2015

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
Copy link
Member

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
Copy link
Author

mitar commented Dec 12, 2015

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
Copy link
Member

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
Copy link
Author

mitar commented Dec 12, 2015

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
Copy link
Member

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
Copy link

caniko commented Aug 8, 2018

Still no WebRTC support? :(

@andrewgodwin
Copy link
Member

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.

@caniko
Copy link

caniko commented Aug 20, 2018

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
Copy link
Member

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

@harry-dev98
Copy link

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants