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

Pieter Hintjens <ph@imatix.com> Mon, 19 April 2010 21:05 UTC

Return-Path: <pieterh@gmail.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 12CD33A694E for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 14:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.471
X-Spam-Level:
X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 wotQL6w5j-NL for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 14:05:42 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id AB1113A67BD for <hybi@ietf.org>; Mon, 19 Apr 2010 14:05:41 -0700 (PDT)
Received: by pvf33 with SMTP id 33so3478892pvf.31 for <hybi@ietf.org>; Mon, 19 Apr 2010 14:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=Vu0LUPwqjNwCyP2SvZiceQxI0tFxtsupaT9fnm5WBnI=; b=d8+4cVbqm7j+alGJBiqCsa2H9UoZujr4eAhFnkJb6OE6Jya7ugvTmDblUvMF5RusTI yaL6e2V8krTlARrhPSg7Bte6uy5uLFw6/43A3r4gVIw/Bw3xj1ANImRcv8JKxUGvFOXo vIapZXXJ1KrCZACnvZ8JToNJS1pKTrE5K+NnI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=QmJvxPsIVXc71K45AOI7VuMLE+lih8s2IjLfbJSiafWND3ahKLBdDnnvq4w7PYxotN wlcq1YYJLoZEdfsGzi/3c7lwF49N0t1fHjXtkWf90vfCcfoSHIXU2lNJ3j+Y9F6FcEtz pki5s2e2APVVk2sXrsAz0euqapxEGAy5EhfpY=
MIME-Version: 1.0
Sender: pieterh@gmail.com
Received: by 10.140.225.18 with HTTP; Mon, 19 Apr 2010 14:05:10 -0700 (PDT)
In-Reply-To: <B3F72E5548B10A4A8E6F4795430F841832040F78ED@NOK-EUMSG-02.mgdnok.nokia.com>
References: <Pine.LNX.4.64.1004181812370.751@ps20323.dreamhostps.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> <B3F72E5548B10A4A8E6F4795430F841832040F78ED@NOK-EUMSG-02.mgdnok.nokia.com>
From: Pieter Hintjens <ph@imatix.com>
Date: Mon, 19 Apr 2010 23:05:10 +0200
X-Google-Sender-Auth: 9aaee5d06e905c6d
Received: by 10.141.187.9 with SMTP id o9mr4875081rvp.211.1271711130710; Mon, 19 Apr 2010 14:05:30 -0700 (PDT)
Message-ID: <r2v5821ea241004191405i24bb2dbbp7d63399720672efc@mail.gmail.com>
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset="ISO-8859-1"
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 21:05:43 -0000

On Mon, Apr 19, 2010 at 10:54 PM,  <Markus.Isomaki@nokia.com> wrote:

> 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?

Here is the logic we used when designing AMQP's KA mechanism.

Let's say we use a req-resp model over a symmetric async connection...

* if the other party is sending us stuff, KA responses are redundant
* If we're sending stuff, KA requests are redundant
* Since we're symmetric, both peers would send requests when idle
* Thus a response is always redundant

And it boils down to sending NOOPs when otherwise idle, to ensure the
other party knows we're still alive (as a process).

Incidentally this simplified async KA is also much easier to
implement, requiring no state at the recipient.

-Pieter