IETF Logo Mail Archive

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

<Markus.Isomaki@nokia.com> Mon, 19 April 2010 20:18 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 D956B3A68AB for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 13:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.226
X-Spam-Level:
X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 NERC3GU1fMev for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 13:18:05 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 10EA83A6452 for <hybi@ietf.org>; Mon, 19 Apr 2010 13:18:04 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3JKHkgn009204; Mon, 19 Apr 2010 15:17:53 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 23:17:49 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 23:17:44 +0300
Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 19 Apr 2010 22:17:44 +0200
From: Markus.Isomaki@nokia.com
To: ph@imatix.com
Date: Mon, 19 Apr 2010 22:17:43 +0200
Thread-Topic: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
Thread-Index: Acrf/D3yI+IafEJXTeC0AlklwndT0wAAGKuQ
Message-ID: <B3F72E5548B10A4A8E6F4795430F841832040F78DB@NOK-EUMSG-02.mgdnok.nokia.com>
References: <Pine.LNX.4.64.1004181812370.751@ps20323.dreamhostps.com> <j2n5c4444771004181403o81184b00r294f3c3b878f24f6@mail.gmail.com> <20100419091736.GA28758@shareable.org> <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>
In-Reply-To: <w2q5821ea241004191309t7362de42p922788d380119dc4@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:17:44.0833 (UTC) FILETIME=[5F13BF10:01CADFFD]
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:18:11 -0000

Pieter Hintjens wrote:
>
>On Mon, Apr 19, 2010 at 9:53 PM,  <Markus.Isomaki@nokia.com> wrote:
>
>> I think the websocket spec should define two special frames 
>explicitly 
>> for keepalive purpose...
>
>For what it's worth, the keep alive design from AMQP used only 
>one frame.  Senders are responsible for issuing KAs at regular 
>intervals.
>Receivers treat these as no-ops except to register "activity" 
>on the connection.  Any other frame also acts as activity, 
>obviously.  If no activity is received within X seconds, the 
>connection can be killed.
>There is no notion of request-response for KA in AMQP.
>

This is another possibility, and it's even simpler. But how fast would the sender be able to detect that the keepalive did not go through and there's something wrong with the connection? Only after TCP has given up? Also an explicit response would tell something more about the liveliness of the server than a mere TCP ack. 

I'd prefer request-response pattern. 

Markus

v2.23.0 | Report a Bug | By Email