I try to combine a WebRTC and Fable for some time in my daily work. I want to describe the process of implementing a signaling mechanism for it.
But at first, what is a WebRTC? WebRTC is a technology that allows exchanging data between N peers via UDP or TCP protocols. Exchange means that there is no server in the middle, but peers talk to each other (except situation when Relay connection is used). WebRTC is a native API available in all modern browsers. One of the things that are not ready by default is the signaling process. About which will be this article.
Before we go into details of implementation. Let’s explain some basic concepts around signaling. To establish a connection between 2 Peers they need to exchange messages with SDP (Session description protocol) information. The number of those messages depends on:
- the number of STUN/TURN server,
- type of connection (P2P/Relay).
SDP contains a lot of information needed to start a connection. Messages that would be exchanged are called Offer, Answer, and Candidates. We gonna use a Trickle-Ice mechanism. It means that the offer, answer, and candidates will be sent separately in an async manner. Candidates have information about “how to connect to a peer which create them” (more about them here). There is also a simpler way of establishing a connection where Answer and Offer would contain all needed candidates. But I want to focus on an async version because we are using it in our product because of better performance.
Switching messages as described above are named “signaling”. When I was looking for some ready to go solution for signaling I find out Ably.io. I decided to give it a try in case of my base application, which should send a file from one peer to another.
When I was reading the Ably.io documentation. I realized that the only functions that I will need would be
subscribe. Which are used in a message channel context. Because of that, I created an Ably interface in F# which is a port of JS interfaces from their official lib.
Changes in packages.json.
I believe that the above code is self-explanatory when we look at the JS example from the Ably site.
Initialization of ably could be found in
Right now, we could go to sending and receiving messages via Ably, but I start with installing the WebRTC-adapter library. This library gives me confidence that what I want to achieve with native API would work the same way in every browser. Since there are some slight differences between implementations.
I add the following line to the packages.json with the
Usage in F# code.
Thanks to the above. I’m sure that the interfaces are compatible across all supported browsers. We could switch to the code which is responsible for handling WebRTC. The code snippet is big because we need to distinguish the
receiver of a file. It is because we don’t have an application on the server-side. I started with the creation of a
PeerConnection object with a communication server address.
Because I test everything locally, I force using a Relay connection. Otherwise, communication would be done via a local network. That would result in skipping the signaling phase (host candidates would be used). Worth mentioning is that using public STUN/TURN servers is not recommended. We are not sure how the configuration looks like and who owns them.
We create a
LifecycleModel object which contains a
RTCDataChannel inside. And create an instance of it. It is created as a mutable field instead of part of the Elmish model. It is because of simplicity (default Thoth serializer couldn’t handle serializing
PeerConnection also passing the whole big object wouldn’t be something that we want to do).
After the creation of the
PeerConnection object. We see that in the UI we have a possibility to connect as
It would result in a distinction of how WebRTC is working and a different value for a
Role field in a model. When we look at how the
sender logic is implemented we start with the creation of
RTCDataChannel. It would be used as a transfer channel between users. The creation of a channel is located in the
Going to the configuration of messages send and received via
Ably. When we are a
sender we want to listen to
Candidate(from the receiver) messages. How it is achieved is visible in below code snippet.
And combination with
Ably channel is visible in
init method from
As we could see we subscribe to all messages with the given keys
receiver-candidate. When they occur we propagate Elmish messages that would be handle in the
receiver scenario the difference is that we don’t create
RTCDataChannel (this is why it is marked as
LifecycleModel). We gather it when the connection would be in a
connecting phase. If it would be created on its own we would receive an invalid state error.
This is why we only subscribe to messages
When a subscription to Ably messages is ready we send an Elmish message
Signaling with a ready channel which is updated in the application model. Whereas the WebRTC configuration is updated with callbacks to functions that need to be handled in a connection/data transfer process.
Assignment of those callbacks and how they are handled is visible in a
RTCDataChannelthrough which data (file) would be transferred.
- Handling connection state (only for diagnostic purposes).
- Handling exchange of candidates.
Configuration of WebRTC is ready on the
We could initiate a connection by clicking the
Connect button. After clicking it the
init method from the
WebRTC module would be called.
Offer via Ably channel and set it as
setLocalDescription method on
PeerConnection object. Right now the application flow is not visible when we look at the code at first. The other side of communication should receive
Offer via Ably channel which would be then propagated as
Offer Elmish message and handle in
It should set
Offer from a
sender as a
RemoteDescription on a
receiver side and in case of success generate
Answer. It would be sent to the
sender via Ably. The important thing to mention here is that after the creation of
Candidates are generated. They shouldn’t be set on the
PeerConnection object before setting
Remote descriptions. Because of that Elmish model has a buffer for
Candidates that could be received before setting
Handling a message that contains
Candidates looks like that.
ConnectionState is set when
Answer are received or when the
DataChannel is open.
As we could see, we only set
RemoteDescription on a
PeerConnection object here.
Right now, if everything succeeds, we should have a WebRTC connection ready. DataChannel is open between our peers. We could go to the code which is responsible for sending files. In UI, there should be a
textBox that reacts on a file drop.
Which is handled in the following way.
SendFile message handling.
onmessage handling on
DataChannel object looks as follows.
blob would be sent via
DataChannel. We pass there also a
msgHandler which is implemented in the following way.
Its responsibility is to receive a
FileBlob and immediately download it. We assume that the file would be always a
png with the name
To sum up, thanks to the
Ably platform I was able to implement
Signaling in a simple way which would be worth consideration during the decision-making phase about “how to achieve Signaling in a most performant way” in my daily work. During some initial tests to compare it with standard HTTP request/response, it looks promising.
Another interesting thing is that a user can see how the messages/connections flow and work on the
Ably dashboard. There is also an information about used quota.
Because there are no built-in signaling solutions Ably is for sure an almost
ready to go alternative which we could use in our scenario. I hope I would be able to compare it with other ways to do signaling in the next articles.
I hope you enjoy it. Thanks for reading!