Search code examples
javascriptweb-servicesnetwork-programmingwebrtc

Is it possible and plausible to implement a WebService over a WebRTC Data Channel?

Is it possible to implement a WebService over a WebRTC Data Channel ?

The idea is:

  • The client makes one https request to the server for signaling and session establishment
  • The client and the server start to communicate via a WebRTC DataChannel bidirectionally

Benefits?:

  • Performance ?
  • Requests goes over one connection and the standard allows for multiple datachannels over the same connection ( ports )
  • Flexible networking topologies
  • UDP
  • End to end encryption
  • The server can send events over the same connection
  • Load balancing could be implemented from a pool of servers client side without a load balancer , or all kinds of different solutions
  • Currently being debated the addition of DataChannels to Workers/Service Workers/ etc https://github.com/w3c/webrtc-extensions/issues/64

Drawbacks:

  • Application specific code for implementing request fragmentation and control over buffer limits
  • [EDIT 3] I don't know how much of a difference in terms of performance and cpu/memory usage will it be against HTTP/2 Stream

Ideas:

  • Clients could be read replicas of the data for sync, or any other applications that are suitable for orbit-db https://github.com/orbitdb/orbit-db in the public IPFS network, the benefit of using orbit-db is that only allows to the owner to make writes, then the server could additionally sign with his key all the data so that the clients could verify and trust it's from the server, that could offload the main server for reads, just an idea.

[EDIT]

I've found this repo: https://github.com/jsmouret/grpc-over-webrtc amazing!

[EDIT2]

Changed Orbit-db idea and removed cluster IPFS after investigating a bit

[EDIT3]

After searching Fetch PROS for HTTP/2 i've found Fetch upload streaming with ReadableStreams, i don't know how much of a difference will it be to run GRPC (bidi) over a WebRTC DataChannel or a HTTP/2 Stream

https://www.chromestatus.com/feature/5274139738767360#:~:text=Fetch%20upload%20streaming%20lets%20web,things%20involved%20with%20network%20requests).

Very cool video explaining the feature: https://www.youtube.com/watch?v=G9PpImUEeUA

Solution

  • Lots of different points here, will try to address them all.

    The idea is 100% feasible. Check out Pion WebRTC's data-channels example. All it takes a single request/response to establish a connection.

    Performance

    Data channels are a much better fit if you are doing latency sensitive work.

    With data channels you can measure backpressure. You can tell how much data has been delivered, and how much has has been queued. If the queue is getting full you know you are sending too much data. Other APIs in the browser don't give you this. There are some future APIs (WebTransport) but they aren't available yet.

    Data channels allow unordered/unreliable delivery. With TCP everything you send will be delivered and in order, this issue is known as head-of-line blocking. That means if you lose a packet all subsequent packets must be delayed. An example would be if you sent 0 1 2 3, if packet 1 hasn't arrived yet 2 and 3 can't be processed yet. Data channels can be configured to give you packets as soon as they arrive.

    I can't give you specific numbers on the CPU/Memory costs of running DTLS+SCTP vs TLS+WebSocket server. It depends on hardware/network you have, what the workload is etc...

    Multiplexing

    You can serve multiple DataChannel streams over a single WebRTC Connection (PeerConnection). You can also serve multiple PeerConnections over a single port.

    Network Transport

    WebRTC can be run over UDP or TCP

    Load Balancing

    This is harder (but not intractable) moving DTLS and SCTP sessions between servers isn't easy with existing libraries. With pion/dtls it has the support to export/resume a session. I don't know support in other libraries however.

    TLS/Websocket is much easier to load balance.

    End to end encryption

    WebRTC has mandatory encryption. This is nice over HTTP 1.1 which might accidentally fall back to non-TLS if configured incorrectly.

    If you want to route a message through the server (and not have the server see it) I don't think what protocol you use matters.

    Topologies

    WebRTC can be run in many different topologies. You can do P2P or Client/Server, and lots of things in between. Depending on what you are building you could build a hybrid mesh. You could create a graph of connections, and deploy servers as needed. This flexibility lets you do some interesting things.

    Hybrid mesh topology

    Hopefully addressed all your points! Happy to discuss further in the comments/will keep editing the question.