Elixir server for WebRTC data channels (or other UDP-like channels)

Questions / Help
,
1

I am trying to build something using Phoenix channels, and as great as they are, I am hitting a wall with something.

Basically, I need to send data to server in “fire and forget” manner. I may also get occasional messages from the server. I am not interested in retries, failures, and correct order of arrival of my (or server’s) messages.

I need a UDP-like connection, and Phoenix channels are TCP-like.

I know WebRTC data channels can be put into “unreliable” mode. This looks like what I need precisely, and I tested it browser-to-browser, this will be alright.

But I failed to find any info on how can I integrate that with Elixir on the server. Any ideas?

It’s not a signaling server I need, but a server that would join WebRTC data channel in similar fashion as browsers do.

1 Like
2

I’m working on a media server that accept UDP using Elixir.

The route that accept the connection is here:
https://github.com/shavit/Diana/blob/master/lib/video_chat/incoming_stream.ex#L16

You are probably looking for this line:
{:ok, _socket} = :gen_udp.open(3001, [:binary, {:active, true}])

Test it:

echo "---> Streaming video ${MEDIA_FILE} at ${FRAMERATE} to the server"
ffmpeg \
  -i $MEDIA_FILE \
  -c:a aac -ar 44100 -ab 128k -ac 2 -strict -2 -c:v libx264 -vb 500k \
  -r $FRAMERATE -s 640x480 -ss 00.000 -f avi \
  udp://127.0.0.1:3001
3

AFAIK there’s nothing in the phoenix channels that require it to be backed by TCP. It’s only at the transport level (handled by the Phoenix.Socket.Transport behaviour), where the semantics are established. It’s true that both of the built-in transport implementations - websockets and longpoll - are tcp-based. But it’s not impossible to have a custom transport backed by raw udp, WebRTC or other solutions that do not have retry semantics.

4

I’m not sure if using Phoenix for accepting UDP makes sense. Phoenix endpoint is powered by Cowboy, so TCP is always underneath. UDP is connectionless, so even if it can somehow be integrated directly into endpoint, I think it would be a needless complication.

If the system needs to handle UDP next to TCP traffic, I’d just start a separate process powered by gen_udp. I think it can even listen on the same port as the endpoint, as the networking protocols are different.

1 Like
5

I was thinking the same, this probably should not be part of the Phoenix pipeline. And @michalmuskala I do not think I need any of the Phoenix channel connection handling mechanisms either. I don’ t need nor want connection established/dropped events, since there’s really no connection involved. All I want is to send and receive messages, as quickly as possible to reduce the latency.

I think I’ll start off by inspecting how WebRTC DataChannel works when two browsers are connected. Wireshark should do the job I think. I imagine this being pretty thin layer over UDP, but let’s see.

I was trying to check if someone did such thing already possibly in Erlang so I don’t have to do all the hard work :wink:

6

@hubertlepicki While it might be possible to do this with phoenix, it might not be the best idea - I forgot to add that to my response :smirk: So I fully agree with you here.

@sasajuric I don’t think the channel has to be started by the cowboy. The transport implementation controls this entirely.

1 Like
7

I’m not familiar enough with the details to offer much help, but I wanted to make sure you were aware of this conference talk which seems relevant
http://confreaks.tv/videos/elixirconf2016-webrtc-and-phoenix-when-seconds-aren-t-fast-enough

8

So why using WebRTC and not UDP which is much simpler and faster? Handshake will slow down the connection.

9

Oh, I wasn’t aware that there is some other way to use UDP directly from browser… I know you can do it using browser extension, but I do not think I can normally from web pages… Can I do it somehow?

10

I didn’t saw that you were looking for a browser solution. I was broadcasting using native apps.

Yes, there is the native (WebRTC) getUserMedia with limited browser support, and also ActionScript that requires Flash player installed.


http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/DatagramSocket.html

11

You’re actually right that a socket can be driven separately, I’ve even blogged about it here. So I guess that Phoenix sockets could be driven through gen_udp. Some uncertainty remains, for example how does the lack of guarantees on message arrival and ordering affect socket/channels semantics, but the idea seems interesting.

12

I’ve done a lot of voice WebRTC with elixir. Typically, the media path for WebRTC is from browser to browser, and the server is not included in the media path unless you need to have the server in the middle of the media path. Phoenix channels are great for the WebRTC signalling portion to setup the media path. I have not used data channels yet, but can’t imagine that they are much different than voice or video.

If you need to anchor the media path on the server, your going to have some difficulties with Elixir/Erlang. Current browsers require that the WebRTC media path use DTLS (TLS over UDP). The last time I checked (6 months ago), there was NO support for DTLS in erlang.

I have a simple Phoenix WebRTC demo project on github you may want to checkout.

Steve

8 Likes
13

Wondering if you ever found out a way to do this, and if Phoenix is a decent choice for it. I’m working on a project where all of our communication is going to be done over Channels, but some of it is going to be updating so quickly that TCP would be pointless (especially since it’s essentially read-only state).

14

It may be worth noting that DTLS-support now is in beta in OTP20.

1 Like
15

I haven’t sorted this out. We are firing the standard HTTP requests for the functionality we need to be not reliable. The resonses sent back are okay if they are sychronous, so we stick to Phoenix channel. It’s not ideal and probably has huge overhaul, but works for now.

16

Here is the relevant change to the docs:
https://github.com/erlang/otp/commit/2726a0bb5e3839913cf9a452ee168e3443f325c6