Re: [rtcweb] realiable data service

[Emil Ivov <[e-mail]>]

На 20.07.11 11:43, Stefan Håkansson LK написа:
> On 2011-07-19 19:09, Serge Lachapelle wrote:
>> There are many very established ways to transfer files from a web
>> browser. Dropbox, Google Docs, yousendit, mobileme, not counting the
>> media specific ways, such as Flickr, Spotify, Youtube, etc... All
>> offering great APIs for uploads, ACLs, etc...
>>
>> Seems like re-inventing the wheel.
> I tend to agree. What the data channel of rtcweb could provide is 
> shorter latency - but to me that does not seem relevant for a file transfer.

I am not so sure about that. Transferring a file directly between you
and your peer is often way faster than relaying through the servers of
well known services. The time necessary to transfer several tens of megs
can very greatly ... from a couple of minutes to an hour or more. Users
are definitely very sensitive to this.

Besides, this is not only about the latency. It's mostly about the
reources that such relayed transfers require on the server side. Most
providers want to bring those to a minimum. So much so, that some even
put relatively low caps on the traffic you can send through the
signalling channel.

For example, the desktop sharing implementation we have in Jitsi uses
signalling (SIP or XMPP) to convey key and mouse events. When using
Google's XMPP service users would regularly experience blockages caused
by the Google service dropping XMPP IQs when they go above a certain
frequency. And this is in no way a criticism for the service itself ...
it is however definitely a reason to have a reliable means of
communicating directly between peers (or at least as directly as possible).

Emil


>>
>> /Serge
>>
>> On Tue, Jul 19, 2011 at 19:02, Emil Ivov <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     На 19.07.11 18:37, Randell Jesup написа:
>>      > On 7/19/2011 11:58 AM, Justin Uberti wrote:
>>      >> At Google, we created a TCP/ICE-UDP layering to solve this exact
>>      >> problem, using a user-mode implementation of TCP. It has some rough
>>      >> edges, but has worked well in practice, and the code is freely
>>     available.
>>      >
>>      > Right; pretty much what I'd anticipate
>>
>>     +1 most definitely. Again, I have yet to see a massively used RTC
>>     application that doesn't have file transfer. So if this is not part of
>>     RTCWEB we will basically be asking developers to reimplement Pseudo TCP
>>     in JavaScript.
>>
>>     Emil
>>
>>      >, and working open code is good.
>>      > SCTP as mentioned is a good choice too, and there exist (it appears)
>>      > SCTP-over-UDP implementations, which may ease things.  Also the
>>      > TCP-over-UDP library I pointed to.
>>      >
>>      >> We know people will want/need a reliable messaging mechanism for p2p
>>      >> data. While we can debate the details of this mechanism at length, I
>>      >> suspect anything we choose will result in a better end-state than if
>>      >> we require application developers to implement their own.
>>      >
>>      > As is obvious from my other messages, I agree wholeheartedly.
>>      >
>>      >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich
>>      >> <[e-mail] <mailto:[e-mail]>
>>     <mailto:[e-mail]
>>     <mailto:[e-mail]>>> wrote:
>>      >>
>>      >>     +1
>>      >>     Maybe it would be useful for the proponents of this and many
>>     other
>>      >>     “desirable” features to think from the perspective if they would
>>      >>     have to pay themselves for such developments and also make the
>>      >>     code freely available.
>>      >>     Cullen at least will make his code available.
>>      >>
>>      >
>>      > See above.  No one here wants to develop *another* reliable
>>     protocol if
>>      > we can avoid it.  I understand your reluctance.
>>      >
>>      > The goal is to produce something that will meet the needs and get
>>     used.
>>      > If we don't meet the
>>      > needs of the prospective users it's either an total waste of time (if
>>      > they ignore this effort and stick
>>      > with Flash/plugins/etc) or we get all sorts of
>>      > hack/bad/problematic/incompatible implementations
>>      > by individual developers using the UDP (or RTP!) streams we open as a
>>      > base transport.
>>      >
>>      > To your point, another way this effort could fail is by biting
>>     off too
>>      > much or taking too long to
>>      > converge, which is a real danger.  That's one reason to leverage
>>      > existing protocols.
>>      >
>>
>>     --
>>     Emil Ivov, Ph.D.                       67000 Strasbourg,
>>     Project Lead                           France
>>     Jitsi
>>     [e-mail] <mailto:[e-mail]>
>>       PHONE: [phone] <tel:%2B33.1.77.62.43.30>
>>     http://jitsi.org                       FAX: [phone]
>>     <tel:%2B33.1.77.62.47.31>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>> --
>> Serge Lachapelle | Product Manager |[e-mail]
>> <mailto:[e-mail]> |[phone]
>> <tel:%2B46%20732%2001%2022%2032>
>> Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880
>>
>> Apparently, this footer is required in Europe. Apologies. This email may
>> be confidential or privileged.  If you received this communication by
>> mistake, please don't forward it to anyone else,please erase all copies
>> and attachments, and please let me know that it went to the wrong
>> person.  Thanks.
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]                        PHONE: [phone]
http://jitsi.org                       FAX:   [phone]