Re: Expose capabilities / Allow for IP:Post based connections / Better abstraction

On 2013-07-09 15:01, piranna@gmail.com wrote:
>>>>> So candidates are mandatory? What's the data that needs to be
>>>>> interchanged? I have seen that up to seven candidates are
>>>>> interchanged, why so much? Couldn't this be made transparent to the
>>>>> user?
>>>>>
>>>>
>>>> Yes. On a high level, the data describes the different ways you may be
>>>> reached. There are many of them to increase the possibility of a
>>>> successful
>>>> connection. I think this part of the API is rather OK. All you have to
>>>> care
>>>> about is sending your generated candidates to the other side.
>>>>
>>> Ok, that way it make sense, althought I would prefer it would be more
>>> simple and transparent like WebSockets... :-P
>>
>> It's is a whole lot easier with a server that's always reachable (it's not a
>> very useful server otherwise). :)
>>
> Yeah, I know :-D Probably I'm too much focused on my own use case (a
> P2P framework and filesharing application. Some people compare its
> architecture with Gnutella network), where anonimity and pure P2P are
> the main corner cases...
>
>
>>> What about creating by default an internal DataChannel to support this
>>> things transparently to the user? Or it would be better to be done on
>>> an upper API as I'm currently doing? Cound candidates being send all
>>> in one message instead of several ones?
>>>
>>
>> The problem with sending candidates over an internal DataChannel is that you
>> can't set up the channel (assuming it's p2p) until you have exchanged
>> candidates since the peers can't reach each other yet. It becomes a chicken
>> and the egg thing.
>>
> Also including them on the offer/answer messages?

Nothing prevents that. It all comes down to what available transports 
you have at the moment. If you have done the initial connection setup, 
you can send sequent offer/answer messages and candidates on a 
DataChannel. But until then, you need some other transport to talk to 
your peer.

>
>
>> You can gather all candidates and then send them. That will take some more
>> time, and if an early candidate was useful then you'll make your
>> communication setup take more time than it had to.
>>
> Ok, I agree it makes some more sense as it's at this moment.
>
>
>>>> I think it's a fair requirement that you use regular web technologies to
>>>> locate who you want to to communicate with; then you can connect to that
>>>> peer with WebRTC.
>>>>
>>> I agree, and in fact I try to use them at widest, but the requeriment
>>> to have a "central" server for handshaking I find it superfluous. I
>>> know you can interchange the SDPs by hand via mail or pidgeons, but
>>> anyway it cumbersome... Ideally, once you create the PeerConnection
>>> object, you should be easy to connect to it someway (the "handshake
>>> signaling", but don't necesarily done by the STUN server...) without
>>> needing to deploy your own server or parasiting another one (as I'm
>>> currently doing).
>>
>>
>> So we're on the same page that regular web technologies should be used in
>> the setup process of WebRTC. Then, are you aware of any web service where
>> two clients communicate with each other without involving a server?
>>
> Web services no, since until now we didn't have support for P2P
> connections... :-D On the other hand, original idea of Tim Berners-Lee
> was Internet being pure P2P, only that client-servers are easier to
> develop, and also there is a discarded W3C proposition to allow web
> pages inside browsers to work as web servers just hooking some paths
> on the "web browser web server" root path and using some dynamic DNS
> magic to access to them... :-) In some way and in the long run, my
> intention with my P2P framework (and in fact the intention of
> everybody currently working and experimenting with DataChannels) is
> somewhat allow to do this use case :-)
>
>
>> Any web-based communication would need a server to exchange messages between
>> clients. For example, in a chat service, you would probably do an XHR to a
>> server to send your chat message to the other participants. If I were to add
>> audio and video to such a call (with WebRTC) I could send the session
>> descriptions via the same server but as a message type other that "chat
>> message". So what I'm saying is that there's no requirement for a "central
>> server" that only does handshaking. A lot of services would send the session
>> descriptions on the same transport between clients as they send other data;
>> for example presence information or chat messages.
>>
> Yes, and in fact I'm using them (PubNub channels, annonimous XMPP
> servers and also my own protocol SimpleSignaling, and I have on the
> radar to be able to use SIP-over-WebSockets), but the fact of parasite
> this services and none of them giving a definitive solution nor found
> a better one yet still give me some hackerish/homebrew/amateur/not
> profesional/not serious sensation... :-/
>

I see. I think what you're trying to achieve is beyond the scope of 
WebRTC. To connect clients p2p without initially locating each other 
using a server is a big deal. Enough that it probably should be done in 
a new working group.

/Adam

Received on Wednesday, 10 July 2013 09:28:19 UTC