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

Dear Adam, two comments inline.

Kind Regards
Johannes

On 07/08/2013 10:27 AM, Adam Bergkvist wrote:
> On 2013-07-08 09:28, piranna@gmail.com wrote:
>> +1, maybe not the best API, but I have always criticed why is so
>> complicated to establish a DataChannel. On my polyfill, following the
>> spec, it didn't seems that you require candidate messages, and common
>> sense say it too.
>
> I assume that your polyfill uses WebSocket as the transport? 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.
But isn't there an underlying issue for you in the current approach? As 
an example, you can ignore the part "Towards ICE" in my last mail, 
because there actually seems to be a way to circumvent the ICE logic 
entirely. Set the constructor value to null and ignore all ICE related 
stuff.

But that realization brought me right back to my original point:
ICE (especially TURN) seems to be totally unneeded for the core 
functionality, yet it's deeply baked into the PeerConnection object. 
Shouldn't it be on its own abstraction and passed in if needed?
Additionally, shouldn't it be possible to instantiate channels without 
caring about the pooling (do it under the hood unless I care?)? So I can 
write new DataChannel(sdp) (or better, ip based).

RTCPeerConnection is not only a transport pool, it's also the factory, 
not for one but numerous things. It has the ICE logic baked in, it has 
the SDP logic baked in, it has all the create* logic.
If this object has to stay, to push the standard out, ... I understand. 
But it for a standard I believe to stay a long time and have a good deal 
of influence, it seems to have some flaws (separation of concerns, 
simplicity in use).
>
> What info do you need to interchange after doing the
>> offer/answer? And also, the direct connection using IP:port using the
>> STUN data would be a good idea (using WebRTCSocket as you propose not).
>>
>> El 08/07/2013 07:15, "Johannes Hange" <moooitic@mailbox.tu-berlin.de
>> <mailto:moooitic@mailbox.tu-berlin.de>> escribió:
>>
>>     Dear WebRTC,
>>
>>     you are the future, and should be carefully build. The current
>>     proposal does not expose the capabilities gained very well.
>>
>>     In general, the standard puts capabilities into a monolithic (pool)
>>     object (for the sake of performance and probably due to SIP
>>     influences). This may be due to a focus on video and audio in the
>>     initial development phase of the protocol, for which this setup is
>>     probably a good idea and common practice.It currently has the
>>     disadvantaged that the developer can't access and use the
>>     functionality separately, has to write complicated code for simple
>>     things and is restricted by predefined flows.
>>
>>     - Objects should be independent from an API perspective:
>>          - Resources (streams) should be pooled under the hood and have
>>     nothing to do with the API
>>          - If necessary expose "pools" the developer can "add" to, not
>>     require them
>>     - Added protocols and gained features should be exposed to the
>>     developer (if there are use cases)
>>          - So he can invent what to do with them
>>          - Example below
>>     - Higher level objects are a good addition, but not a good base
>>     abstraction.
>>          - Once you have a monolith, breaking it up in a lib is ugly,
>>     the other way around is not (Look at the code that exists today to
>>     do this ...)
>>
>>     This was written under the assumption that much of the existing
>>     infrastructure is used and little adapted. I suggest a dual approach
>>     where small exposed objects and the current big monolith co-exist
>>     (lets see who wins in 2.0 by analyzing usage ...).
>>
>>      From a data channel / web developer perspective the API and
>>     requirements are overly complicated and lack the abilities to:
>>          1 - Establish a connection to another user directly, based on
>>     the exchange of ip:port pairs (not large SPD)
>>              - [RTCPeerConnection.]connect(ip, port, [timeout], [number]
>>     ...)
>>                  - punches holes until [timeout], [number] may be useful
>>     to regulate the number of punches
>>                  - various security restrictions to address flooding /
>>     miss-use, but does not differ from current attack vectors
>>              - onconnect / callback
>>                  - continue flow (exchange SDP)
>>          2 - Find out the IP of the current system
>>              - getIPAddresses(['stun: ...', 'stun: ....'], ...)
>>                  - Provide a call outside of the webrtc object
>>          3 - Provide a simple WebRTCSocket alternative to send data
>>              - WebRTCSocket("to_ip:to_port", "my_ip:my_port" /*obtained
>>     via navigator.getIPAddress(stunServers)*/)
>>                  - Which does the following (probably implemented more
>>     efficiently):
>>                      - RTCPeerConnection.connect(to_ip, to_port);
>>                      - createDataChannel
>>                      - Expose events of the data channel
>>              - This can be done for audio/video too in order to break up
>>     the monolithic nature ...
>>
>>     Towards ICE:
>>          - Build own Http flows and provide the ability to solve the
>>     problem without ICE:
>>              - {'iceServers': [{'url': 'https://example.org/myip'}]};
>>                  - For most clients this will provide me a valid address
>>     for later hole punching and it's easy to create
>>                  - Return any answer format the developer chooses,
>>     client code knows what to do
>>                  - I can start signaling logic at this point already
>>     (and close my server to the public)
>>              - Client must convert IP into a SPD format for exchange
>>                  - createOffer(ip, function(description) {....})
>>
>>     Kind regards and thanks for reading
>>     Johannes H.
>>
>>     PS: I am glad to answer anything unclear or address issues
>>     (participate in discussions)
>
> The web app can't set it's own ports and the receiver ip/ports for
> security reasons. 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/
>
Thank you very much! I suspected that this would be problematic. But 
couldn't you do a handshake on a pre-set port and automatically switch 
to another by negotiating? So connect("ip", [time]). I will read the 
links asap.!
Isn't this also a problem with SDP files? To freely change connection 
details? Can't I write a local js attack that does exactly this?

Received on Monday, 8 July 2013 12:02:43 UTC