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

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.

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/

Received on Monday, 8 July 2013 08:28:10 UTC