Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

Greg Wilkins <gregw@intalio.com> Wed, 25 May 2011 22:48 UTC

Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6A7E07FB for <hybi@ietfa.amsl.com>; Wed, 25 May 2011 15:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.944
X-Spam-Level:
X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqqhUv5u6QKL for <hybi@ietfa.amsl.com>; Wed, 25 May 2011 15:48:44 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1EBFE06E5 for <hybi@ietf.org>; Wed, 25 May 2011 15:48:43 -0700 (PDT)
Received: by vxg33 with SMTP id 33so134805vxg.31 for <hybi@ietf.org>; Wed, 25 May 2011 15:48:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.186.133 with SMTP id fk5mr189273vdc.184.1306363723248; Wed, 25 May 2011 15:48:43 -0700 (PDT)
Received: by 10.52.187.71 with HTTP; Wed, 25 May 2011 15:48:43 -0700 (PDT)
In-Reply-To: <4DD9686C.7020509@callenish.com>
References: <ED13A76FCE9E96498B049688227AEA292C6A81E4@TK5EX14MBXC206.redmond.corp.microsoft.com> <4DD9686C.7020509@callenish.com>
Date: Thu, 26 May 2011 08:48:43 +1000
Message-ID: <BANLkTimy+HT3HbSj5_6gUrYm_JGGLP9-6A@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Bruce Atherton <bruce@callenish.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 25 May 2011 22:48:44 -0000

+1 to all this.

On 23 May 2011 05:47, Bruce Atherton <bruce@callenish.com> wrote:
> It seems there are still a number of issues around Ping/Pong. Here are my
> thoughts on them:
>
> 1) Should multiple Pings be allowed before a response Pong is received?
>
> Surely this is the business of the implementation/application and not the
> specification. If someone has a use for such a thing, why not allow it?
>
> 2) Should Ping and Pong be allowed to have a body?
>
> I think it is a useful and desirable feature. It allows matching Pongs to
> Pings, as well as being an area for experimenting with new ideas in how the
> Ping and Pong are used.
>
> The argument has been brought up that the bodies are useless without a
> standard way of interpreting them. This is absolutely true. Why not allow
> experimentation so that people can come up with standards for them?
>
> What is the downside to allowing it?
>
> 3) Should there be an indicator for unsolicited Pongs and/or Pings that need
> no response.
>
> I don't see why this is necessary or desirable so long as the body of the
> Pong in some way indicates the Ping it is responding to. Allowing
> unsolicited Pongs removes any usecase for Pings without responses as far as
> I can see. As far as unsolicited Pongs go, if the Pong body does not match a
> Ping that was sent out, then surely it can be assumed to be an unsolicited
> Pong.
>
> What is the marker trying to indicate? That if we have a Pong that claims to
> be solicited and does not match the Ping body that there is a bug in the
> server implementation, or perhaps that the server is mistaken in the client
> it thinks it is communicating with? Is this really necessary?
>
> 4) Should we allow the Pong body to contain extra data beyond just echoing
> the Ping body?
>
> Again, I think this is a harmless way to allow experimentation on uses for
> Ping and Pong. I don't see any reason for disallowing it.
>
> It has been claimed that there could not be any value in allowing additional
> information because Ping/Pong frames run at a higher priority than other
> Websocket traffic, and so any data they carry on network characteristics
> would not reflect the behaviour of other data in the channel. This makes a
> couple of assumptions that I think are questionable. First, are all possible
> uses of Ping and Pong concerned with network characteristics? Even if so,
> are all possible network characteristics rendered moot by higher priority
> traffic? I don't see it necessarily follows that these two assumptions are
> valid.
>
> So if it were up to me, I would just change the spec to indicate that the
> Pong must respond with the Ping body, but is allowed to add any data it
> wishes to afterward. In fact, you could even change it to respond with just
> a hash of the Ping body followed by any other data it wanted to (SHA1 +
> Base64 for consistency).
>
> I wouldn't add in a flag for unsolicited vs. solicited Pongs since the Pong
> response does that for us by indicating the Ping it is responding to, but if
> others wanted it then I wouldn't stand in their way. Although, if you are
> going to specify a byte for a single flag then you may want to indicate the
> other 7 bits are reserved for future use.
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>