IETF Logo Mail Archive

Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?

<Markus.Isomaki@nokia.com> Mon, 19 April 2010 20:55 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0503A6A05 for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 13:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.351
X-Spam-Level:
X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0jJryRpoAtA for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 13:55:19 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 781613A6A61 for <hybi@ietf.org>; Mon, 19 Apr 2010 13:55:17 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3JKt0pJ022383; Mon, 19 Apr 2010 23:55:01 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 23:55:00 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 23:55:00 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 23:54:55 +0300
Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 19 Apr 2010 22:54:55 +0200
From: Markus.Isomaki@nokia.com
To: ph@imatix.com
Date: Mon, 19 Apr 2010 22:54:54 +0200
Thread-Topic: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
Thread-Index: Acrf/p+MMyYe9BypRxC45UmzgMT7FQAAGn8g
Message-ID: <B3F72E5548B10A4A8E6F4795430F841832040F78ED@NOK-EUMSG-02.mgdnok.nokia.com>
References: <Pine.LNX.4.64.1004181812370.751@ps20323.dreamhostps.com> <p2w2a10ed241004190222ne3a61417i47b021dbe0422f71@mail.gmail.com> <B3F72E5548B10A4A8E6F4795430F841832040920C4@NOK-EUMSG-02.mgdnok.nokia.com> <20100419121000.GG28758@shareable.org> <87764B8E-5872-40EE-AA2F-D4E659B94F63@d2dx.com> <20100419140423.GC3631@shareable.org> <6959E9B3-B1AC-4AFB-A53D-AB3BA340208C@d2dx.com> <B3F72E5548B10A4A8E6F4795430F841832040F78C0@NOK-EUMSG-02.mgdnok.nokia.com> <w2q5821ea241004191309t7362de42p922788d380119dc4@mail.gmail.com> <B3F72E5548B10A4A8E6F4795430F841832040F78DB@NOK-EUMSG-02.mgdnok.nokia.com> <l2v5821ea241004191326i50970f32zbda7f876eda777f1@mail.gmail.com>
In-Reply-To: <l2v5821ea241004191326i50970f32zbda7f876eda777f1@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Apr 2010 20:54:55.0404 (UTC) FILETIME=[9099DEC0:01CAE002]
X-Nokia-AV: Clean
Cc: hybi@ietf.org
Subject: Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 20:55:20 -0000

Hi Pieter,

Pieter Hintjens wrote:
>
>On Mon, Apr 19, 2010 at 10:17 PM,  <Markus.Isomaki@nokia.com> wrote:
>
>> I'd prefer request-response pattern.
>
>Which works only if the protocol is fully synchronous.  I 
>thought WebSockets was async...?
>

Hmm... Even if the protocol as a whole is asynchronous (both ends can generate frames at any time), isn't it still possible to exchange requests and responses as well over the same transport connection?

I guess a special situation arises when a client sends out a keepalive request and before responding, the server starts to send a data frame in the other direction (since these two events can happen asynchronously). But then the server just has to put the keepalive response in its sending queue. (In that case such a response would seem a bit redundant, since the client can see that the connection is up when it receives the data frame). I assume it would still possible to match the response to the request. 

Or am I missing something obvious here? 

Markus

v2.23.0 | Report a Bug | By Email