Distributed Signalling Server about foglet-signaling-server HOT 3 CLOSED

For the moment, this signaling server is a single HTTP server storing WebRTC offers temporarily for the very first creation of a WebRTC connection. What do you mean about "distributed network"? is it to distribute the signaling mechanism among a network of peers? or to distribute the load of the HTTP server among a set of servers?

from foglet-signaling-server.

I'm talking about distributing the signalling mechanism among a network of peers.

this signaling server is a single HTTP server storing WebRTC offers temporarily for the very first creation of a WebRTC connection.

As an analogue to this, I'm proposing a network of peers with the explicit purpose of facilitating this initial WebRTC SDP discovery based on a common topic of interest. That could serve as the signalling layer of any WebRTC based application. It seems like that kind of a signalling network is the missing piece in the WebRTC puzzle for distributed application developers

from foglet-signaling-server.

@quixote911 The problem with this kind of discovery is to send the answer to the initiator. In our own network implementations we only use the signaling server for the very first creation. Once you enter the network, other offers are not forwarded to the server. We use already created connections to forward offers and create newly connections between peers. But this mechanism is suitable only in the context of creating neighbor-to-neighbor connections such as: A is connected to B, B connected to C. Then If A wants to connect to C, B will forward offers and answers from A to C, and from C to A in order to create the connection. Otherwise you'll need to send/receive offers by routing them (aka, using key-based routing or even semantic routing).

Another aspect you mention is to create a specialized network of peers dedicated to this purpose.
But you'll have the same problem of answering accepted offers. How do you do that? by using WebRTC connection (but you need to create this connection...). Currently the only technology/thing that can forward multiple answers/offers is WebSockets. Even in HTTP/(2) it's not possible, you'll need to re-initialized an HTTP request to the server each time you receive an offer in order to get all newly offers (I mean, if you use the trickle = true option, otherwise an HTTP server is enough ;) )

Secondly, and this is my opinion. The strength of the WebRTC discovery mechanism is to be able to create specialized networks on demand. You just need to create a room (a network identifier if you prefer) then forward this demand/offer to someone that can answer to this request (e.g. a P2P network of HTTP/WebSockets servers) storing, discussing, sharing, routing, offers to the server responsible of managing this room.
Creating a shared discovery layer for all WebRTC-based application is a good idea (for public applications for example) but it breaks the entrance mechanism into a network. Thus, it could be a security issue that could not be controlled by the developper when creating its own network. I mean, you could have an auth server, delivering authentication and signaling mechanism for all applications of a compagny. With a shared signaling mechanism, you cannot join/mix both services into one place (one server). To my mind, creating WebRTC applications has its own programming paradigm, where you need to think about: the topology of your network (few peers or a lot of? such as millions of peers); the entrance into the network (aka the signaling mechanism), the application, and data that could be sent over the network (eg, streaming sounds or videos, etc...), then the leaving mechanism, how my topology will react to departures? etc....

After reading you again, I think what you're looking for is what I wrote in the beginning of this message. Aka; creating connections inside the network. If for you, using the signaling server needs to be done for every single connection establishment, then you're surely missing some reflection about the network topology of your application. I hope your network topology is not fixed because it wont scale at all otherwise!

I agree that the missing piece in WebRTC network is this signaling mechanism which is very annoying to develop again and again for every WebRTC application. So i'm glad to exchange more about it if you want to continue the discussion.

from foglet-signaling-server.