Re: Signaling server... necesary?

On 11/10/12 5:44 PM, piranna@gmail.com wrote:
> As far as I know, TURN and STUN servers have some way to communicate
> with the peers and participate stablishing the peer-to-peer
> communication. There would be any way to send a random message with the
> localDescription SDP to the TURN/STUN server (ours or the other end) so
> the other peer would be able to have it and start communication? And if
> not, is it just an API/protocol issue or a technical one and why?

How are you going to identify the other end? Having the STUN/TURN server 
be your signaling channel is possible, but you would have to change the 
spec to allow that to happen, or implement a custom extension. 
Effectively, you are still creating a signaling server, the only 
difference being that they run on the same machine (which you can 
already do) - so I don't see the benefit.

Also, public STUN servers are cheap to run precisely because they don't 
need to ferry around much data. If we add in signaling, it may no longer 
be viable to run them.

> If you are asking about a use case of this, this would allow to develop
> pure client-side webapps with P2P communications without servers at all.
> Currently I'm doing experiments with DataChannels and I need a server
> (https://github.com/piranna/SimpleSignaling) to do the handshake between
> the peers, but it's just doing registration of the peers with a UUID and
> in fact is only being used to send the SDP to the other end (more or
> less 100 lines of code), so it's a little bit oversluous to need a
> machine just for this kind of routing...

If you come up with a naming/identification scheme for all the machines 
on your network, you could probably do this in an entirely P2P fashion, 
but it's a complex undertaking. DHTs are suitable for this kind of 
thing, and Telehash (http://telehash.org/) is a good place to start if 
you're looking to implement signaling entirely peer to peer.

-Anant

Received on Sunday, 11 November 2012 02:27:47 UTC