Signal via Websocket or rest

[Ben Mark]

Hi Janusers, good day to all of you,

I'm building an async WebRTC signalling server and I stoped and wondered what would be the better option:

to signal via REST or via WebSocket per every client/browser

my doubts:

Is Janus a thread per socket connection / rest request?

if so, wouldn't it be silly to keep a socket open per each client since it will dispatch a new thread per every client?

second doubt, since my server is just a signllaing server, short bursts of input output (sessionId handleId , plugin action etc.. ) 

shouldn't this fact make my decision towards REST? 

Thanks in advanced

~Ben

[Lorenzo Miniero]

Not sure what your question is, but Janus can't be used as a simple signalling server for P2P, it forces media to go through Janus as well.

L.

[Ben Mark]

I suspect you got my question wrong, I'll try better to rephrase & elaborate more regarding our janus use-case

Our WebRTC signalling flow:

browser requests to either publish or subscribe to a janus media server through our custom signalling server

Our signalling server is connected to each browser via websocket, and signals (sends reguests to the janus media server) via REST

important to add that we migrated from a blocking i/o , thread per connection (thread per proxy socket connection) to a non blocking i/o signalling server

Iv'e added that since in the past we used to establish the signalling dialog with the client and the browser via websocket (through our signalling server)

Now once we redesigned the blocking i/o server, we prefer to use REST for the signalling issue.

So my question is:

Will there be any consequence from the janus media server when sending it REST posts /gets instead of websocket per each client?

I witnessed that janus media server on a C5xLarge AWS virtual machine can hold up a max limit of 800 peer connections. 

Since the dialog that is required to establish a webrtc connection with a browser and janus is considerably short,

I assume REST should be the better option, instead of opening and closing a websocket per each client just for a simple negotiation like this  (create: sessionId, handleId, plugin request, plugin configure)

[Lorenzo Miniero]

Il giorno martedì 28 agosto 2018 13:53:50 UTC+2, Ben Mark ha scritto:

I suspect you got my question wrong, I'll try better to rephrase & elaborate more regarding our janus use-case

Our WebRTC signalling flow:

browser requests to either publish or subscribe to a janus media server through our custom signalling server

Our signalling server is connected to each browser via websocket, and signals (sends reguests to the janus media server) via REST

important to add that we migrated from a blocking i/o , thread per connection (thread per proxy socket connection) to a non blocking i/o signalling server

Iv'e added that since in the past we used to establish the signalling dialog with the client and the browser via websocket (through our signalling server)

Now once we redesigned the blocking i/o server, we prefer to use REST for the signalling issue.

So my question is:

Will there be any consequence from the janus media server when sending it REST posts /gets instead of websocket per each client?

I witnessed that janus media server on a C5xLarge AWS virtual machine can hold up a max limit of 800 peer connections. 

The limitation you see is caused by a problem in libnice: https://gitlab.freedesktop.org/libnice/libnice/merge_requests/12

We never did any benchmarking test for the different transports, but neither should have a major impact, and can be considered neglectible when compared to media. In general, I'd say that the WebSockets transport is probably more efficient than the HTTP one, as it uses less bandwidth (no long polling) and only uses a single thread (in the HTTP plugin it's a thread per connection). Don't forget that even with REST you need session management, which means keepalives and long polls to get events at the very least.

Lorenzo

[Ben Mark]

Regarding the long polls, it seems that the time it takes to unleash the sdp answer for a publisher request or the sdp offer for a subscriber request is very short,
What is the scenario where I'll force the janus to get into a long poll?

regarding the keep alives, I would really appreciate if you can comment on my post I just added, since I think the keep-alive is a subject of its own

https://groups.google.com/forum/#!topic/meetecho-janus/wTbKDevFg6M

[Lorenzo Miniero]

When you use HTTP with Janus, long polls are needed all the time: https://janus.conf.meetecho.com/docs/rest

Most if not all of the plugin responses, whether they include an SDP or not, will be events, which means they'll only be sent to the user they're meant to if there's a long poll active for the session. In general, long polls are known to be less efficient than a single connection, if not for the fact that multiple connections are used and there's overhead due to the extra HTTP headers for each request. I'm sure there are hundreds of posts explaining the pros and cons of using long polls or websockets, for instance.

Lorenzo