W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 9 Jul 2013 07:41:50 +0200
Message-ID: <51DBA29E.6040608@ericsson.com>
To: "piranna@gmail.com" <piranna@gmail.com>
CC: Johannes Hange <moooitic@mailbox.tu-berlin.de>, public-webrtc <public-webrtc@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:34 UTC