W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Keeping up data channel

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 13 Jun 2012 15:45:04 +0200
Message-ID: <4FD89960.4000502@ericsson.com>
To: SUN Yang <sun.yang.nj@gmail.com>
CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2012-06-13 15:36, SUN Yang wrote:
>
>
> On Wed, Jun 13, 2012 at 4:15 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 06/12/2012 07:36 AM, Harald Alvestrand wrote:
>
>         On 06/11/2012 03:58 PM, Markus.Isomaki@nokia.com
>         <mailto:Markus.Isomaki@nokia.com> wrote:
>
>             Hi,
>
>             In today's WebRTC meeting a discussion came up on how costly
>             it is
>             to keep an unused data channel connected.
>
>             As long as we are using UDP, it is extremely costly for cellular
>             connected mobile devices. In many networks keep-alives at least
>             every 30 seconds are neeed to keep the UDP flow alive.
>
>         We also have to send something every 30 seconds to keep the
>         consent-to-receive alive in the case of media (and to maintain NAT
>         mappings). So as long as a PeerConnection remains unclosed, I think
>         we should assume that a packet will be sent every 30 seconds.
>
>
>     I agree, and I also think this is more of a PeerConnection than a
>     data channel issue.
>
>     I think we need to make developers close the PeerConnection when it
>     is not needed. A way to promote this would of course be to make
>     PeerConnection set up fast.
>
> Why set up PeerConnection fast means closing PeerConnection when not needed?

It just a guess of how developers will behave. If it takes long to setup 
a PeerConnection it's likely that developers won't close it unless 
they're sure that it won't be used again. If it's quick and easy to 
setup again, they might consider closing it.

/Adam
Received on Wednesday, 13 June 2012 13:45:42 UTC

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