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

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

:~:text=Fetch%20upload%20streaming%20lets%20web,things%20involved%20with%20network%20requests).

Very cool video explaining the feature:

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 municate 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./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./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./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./feature/5274139738767360#:~:text=Fetch%20upload%20streaming%20lets%20web,things%20involved%20with%20network%20requests).

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

• javascript
• web-services
• network-programming
• webrtc

• This is a great question. Did you happen to e up with any findings related to overhead/performance differences between WebSockets vs WebRTC Data Channel? We often hear cases in which a server can open hundreds of thousands of WebSocket connections, but haven't heard something similar for WebRTC PeerConnection at the server side. – user482594 Commented Nov 2, 2021 at 3:26

3 Answers 3

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.

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

I was also wondering about this HTTP-over-WebRTC DataChannel idea a couple of years ago. The problem at hand was how to securely connect from a web app to an IoT device (raspberry pi) that sits behind a firewall.

Since there was no readily available solution, I ended up building a prototype. It did the job and has been in live deployment since 2019.

See this technical blog post that covers the design and implementation in more detail: https://webrtchacks./private-home-surveillance-with-the-webrtc-datachannel/

High level architecture:

Simplified sequence diagram:

Recently began the process of extracting the code into a standalone repo.

https://github./ambianic/peerfetch

If your main use-case exchanges small content, you may have a look at CoAP RFC 7252. A peer may easily implement both roles, client and server, though the exchanged messages for request and response share the same fomat.

For some advanced usage of DTLS 1.2, DTLS Connection ID can do some magic for you.

If you don't stick to javascript and java is an option, you may check the open source project Eclipse/Californium. That's a CoAP/DTLS implementation, which es with DTLS Connection ID and some prepared advanced examples as built-in-cid-load-balancer-support or DTLS-graceful-restart.