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

On 2013-07-08 12:31, piranna@gmail.com wrote:
>> I assume that your polyfill uses WebSocket as the transport?
>
> Yes, my polifill
> (https://github.com/ShareIt-project/DataChannel-polyfill) is using
> WebSockets as underlying data transport (UDT on the WebRTC
> specification).
>
>
>> In that case
>> you connect the two peers via a server (and not peer-to-peer); hence no need
>> to exchange candidates. The majority of the code (and the complicated parts)
>> in the DataChannel example (in the spec), is actually connecting the two
>> peers. Once you have that, creating a DataChannel is rather easy.
>>
> 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.

>
>> The web app can't set it's own ports and the receiver ip/ports for security
>> reasons.
>
> I totally agree, publicly allow random connection with IP:port is a
> security issue, but there should be an option to directly connect
> without needing a handshake server and having at most the STUN data.
> At this moment I'm using UUIDs to identify the peers on the server and
> interchange the SDP strings, but there should be an easier,
> no-server-dependent solution to be able to develop a real serverless
> P2P architecture...
>

I think I've asked this question before, but how do you find the person 
you want to talk to in this case? Some entity would have to have a 
register that describes how everyone, for example on your contact list, 
can be reached; are you saying that you want the STUN server to have that?

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.

>
>> Compare WebSockets [1], which similarly to WebRTC is exposed in
>> regular browsers, to the Raw Socket API [2] that developed in SysApps which
>> is targeting packaged applications and other cases where you have a manifest
>> and the app runs in an elevated security mode.
>>
>> /Adam
>>
>> [1] http://dev.w3.org/html5/websockets/
>> [2] http://www.w3.org/2012/sysapps/raw-sockets/
>>
> Oh, well... good to know about raw-sockets, but seems really crazy as
> a solution... Isn't there any solution half-way from raw-sockets to
> websockets/datachannels, or couldn't be able to be developed?
>

I guess there was a lot of discussion before the two above alternatives 
were decided on. Perhaps you'll find some info looking there.

> --
> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
> monton de sitios diferentes, simplemente escribe un sistema operativo
> Unix."
> – Linus Tordvals, creador del sistema operativo Linux
>

Received on Tuesday, 9 July 2013 05:42:15 UTC