Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching

<Markus.Isomaki@nokia.com> Tue, 04 October 2011 09:52 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776821F8C5A for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 02:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level:
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3FQK2UvfMfr for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 02:52:56 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E33A321F8C57 for <rtcweb@ietf.org>; Tue, 4 Oct 2011 02:52:55 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p949tYOB010287; Tue, 4 Oct 2011 12:55:57 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 12:55:31 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 4 Oct 2011 11:53:55 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Tue, 4 Oct 2011 11:53:55 +0200
From: <Markus.Isomaki@nokia.com>
To: <ibc@aliax.net>
Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050b///5dcA//56Y7A=
Date: Tue, 4 Oct 2011 09:53:55 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620D4070@008-AM1MPN1-043.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com> <CALiegf=PU3ec6dSh-9NBLrTz7Q8HJb74WitqfmV+2sHqucDyMA@mail.gmail.com>
In-Reply-To: <CALiegf=PU3ec6dSh-9NBLrTz7Q8HJb74WitqfmV+2sHqucDyMA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.75.37]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Oct 2011 09:55:31.0301 (UTC) FILETIME=[C0BB9950:01CC827B]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 09:52:56 -0000

Hi, 

Iñaki Baz Castillo wrote:
>
>In WebSocket a disconnect() event will be called by JS API if the connection is
>terminated (this can occur when the server explicity terminates the
>connection or when the WebSocket client tries to send a message over the
>WebSocket connection and gets an error because the connection "does not
>work anymore"). For the last case, a pinging mechanism from the client is a
>good choice.
>

Is it possible for the browser to call disconnect() also for more explicit reasons, such that it has itself learned that the current interface/socket has become disconnected? This way the JS application would get the signal immediately rather than having to wait for the next ping. In that case this should be OK. The disconnect() function should then have the code for re-creating the websocket connection, this time over the new (default) interface, and recreating the necessary state on top of it in the application level. This would create a few seconds of disconnect between the client and the server, which might be OK for most apps. Perfect handling of this case, i.e. being able to open the new connection before the old one is lost, would probably require changes in the Websocket API. Or, use of MPTCP.

Markus