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 as transport instead of TCP #210

Closed
traverseda opened this issue May 20, 2018 · 9 comments
Closed

Use webrtc as transport instead of TCP #210

traverseda opened this issue May 20, 2018 · 9 comments

Comments

@traverseda
Copy link

Using webrtc as a default transport would let web-based clients communicate with one another, peer-to-peer, without an the user needing to install a desktop app.

@staltz
Copy link
Member

staltz commented May 20, 2018

But you also need a database :)

@traverseda
Copy link
Author

traverseda commented May 20, 2018

Yeah, mostly I didn't want to open up a bunch of issues for the different parts untill I saw how this was received. IndexedDB is available in most relevent browsers now, and there are filesystem implementations built on top of it. I don't imagine porting flume to be a huge problem. They also recently increased performance of write operations, so the "many small writes" might just work better now?

As an aside, I missed #179 during my search, because I was looking specifically for webrtc.

@staltz
Copy link
Member

staltz commented May 20, 2018

We've had efforts to build scuttlebot on top of indexeddb but it's pretty bad quality when compared to leveldb. I haven't been involved with the implementation but I heard there are a lot of problems with it. And regarding WebRTC, @pietgeursen is working on doing that

@cryptix
Copy link
Member

cryptix commented May 21, 2018

Instead? I find that a bit over the top.

IIRC one also needs a signaling server to make a sctp-wrapped-in-udp connection. Pubs could do that but last time I checked we wanted to reduce their importance..

@dominictarr
Copy link
Contributor

@traverseda we do intend to support webrtc (and utp) as well as tcp and ws, see
https://github.com/ssbc/multiserver/
but there are some hoops to jump through, and I've heard reports that webrtc is really heavy (you can crash a browser by just by creating lots of connections)

Also, indexeddb is slow in my measurements, but if we had a polyfil for https://github.com/flumedb/flumeview-reduce and https://github.com/flumedb/flumeview-level we could at least get something running. Any help here would be much appreciated! getting the secure-scuttlebutt tests passing in a browser context should be the first objective

@Serkan-devel
Copy link

But isn't WebRTC built on top of TCP? And what database does ssb use?

@fermuch
Copy link

fermuch commented Jun 28, 2018

@Serkan-devel WebRTC can work with both UDP and TCP. Peer connections AFAIK use SCTP, which runs on top of UDP.

@traverseda
Copy link
Author

But isn't WebRTC built on top of TCP? And what database does ssb use?

Yes, WebRTC is built on top of TCP. But if SSB is running in a web-browser, it can't use TCP directly, in can only use a limited subset of protocols, most of which are built on top of TCP.

I am presuming that someone is going to write a TCP over webRTC implementation any day now...

@Serkan-devel
Copy link

But under which license?

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

6 participants