Re: [hybi] Clarify the role of closing handshake

Ian Fette (イアンフェッティ) <ifette@google.com> Tue, 15 February 2011 22:27 UTC

Return-Path: <ifette@google.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 CAAC83A6D7C for <hybi@core3.amsl.com>; Tue, 15 Feb 2011 14:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.931
X-Spam-Level:
X-Spam-Status: No, score=-104.931 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1k46K9Dp7rJh for <hybi@core3.amsl.com>; Tue, 15 Feb 2011 14:27:36 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B839E3A6DE9 for <hybi@ietf.org>; Tue, 15 Feb 2011 14:27:35 -0800 (PST)
Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p1FMS1KT008644 for <hybi@ietf.org>; Tue, 15 Feb 2011 14:28:01 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297808882; bh=JITlnhZZpelMYXOoniS2Zp1rmJc=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=mh2elXbgvY1xl2l/isf+Fs0Ysw9+XKSbs00MozZnVASaUUBDKHTfsdkyP3227MPkx lLJBw0hu+spA2fyXxuunw==
Received: from iwc10 (iwc10.prod.google.com [10.241.65.138]) by kpbe15.cbf.corp.google.com with ESMTP id p1FMRcD7019971 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 15 Feb 2011 14:28:00 -0800
Received: by iwc10 with SMTP id 10so697687iwc.0 for <hybi@ietf.org>; Tue, 15 Feb 2011 14:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yh+5vdh6ECFQnoUjhiWUY24YuTBiE4nzoDTlilrqZas=; b=UiXRtu7YPbTxGYE1C/+5FWrs/nrb02etgdk06fkOzuDOv5SaychK/RdfMWQP7OtN8G rzrWtjOD/jG4vlViKwXg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=cr9oiix/WsEvabmk9tM6Zj1XQMdcUULfjoOXxXO8/lT5j8rgIXQpv79SWI0N3T8aG3 3+XOkHCjKMUyBR8Z/0Gw==
MIME-Version: 1.0
Received: by 10.42.229.7 with SMTP id jg7mr7449681icb.211.1297808879123; Tue, 15 Feb 2011 14:27:59 -0800 (PST)
Received: by 10.231.37.133 with HTTP; Tue, 15 Feb 2011 14:27:58 -0800 (PST)
In-Reply-To: <OF9E69202E.36384265-ON88257838.00749E83-88257838.007782CA@playstation.sony.com>
References: <4D5AE318.9080308@stpeter.im> <OF9E69202E.36384265-ON88257838.00749E83-88257838.007782CA@playstation.sony.com>
Date: Tue, 15 Feb 2011 14:27:58 -0800
Message-ID: <AANLkTinXR_kTQ2vFt8AqLWPJd1XYxMxuhbVwGgRGqKO0@mail.gmail.com>
From: "Ian Fette (イアンフェッティ)" <ifette@google.com>
To: Yutaka_Takeda@playstation.sony.com
Content-Type: multipart/alternative; boundary="20cf30549dcf39fc94049c59ade8"
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Clarify the role of closing handshake
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ifette@google.com
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: Tue, 15 Feb 2011 22:27:38 -0000

On Tue, Feb 15, 2011 at 1:45 PM, <Yutaka_Takeda@playstation.sony.com> wrote:

>
> Okay, I admit my example was bad.
>
> Just to be clear, even with this code:
>
>       websocket.send("a-message-needs-to-reach-server")
>       websocket.close()
>
> From your opinions, programmers should not expect that the message always
> reach the server. (granted)
>
> Now, here's another question for you.
>
> If onclose() callback is made on the websocket, would it be helpful if that
> callback (with wasClean=true) guarantees
> that the message has been delivered to the server?
>
>
I am not sure how many people would use it, but I think it would be
straightforward and cheap to provide that information so I wouldn't have any
problem with it.

I am trying to get out a -06 that resolves some of the CLOSE issues, but
currently I'm getting caught up by a few other things at work today.

What I'm currently looking at is this: (comments welcome)

         <t>The Close message contains an opcode of 0x01.</t>
          <t>The Close message contains no body (the body has zero
length).</t>
          <t>The application MUST NOT send any more data messages after
sending
          a close message.</t>
          <t>If an endpoint receives a Close message and that endpoint did
not
          previously send a Close message, the endpoint MUST send a Close
          message in response. It SHOULD do so as soon as is practical.
          </t>
          <t>After both sending and receiving a close message, an endpoint
          considers the websocket connection closed, and
          SHOULD close the underlying TCP connection.</t>
          <t>If a client and server both send a Close message at the same
time,
          both endpoints will have sent and received a Close message and
should
          consider the websocket connection closed and close the underlying
          TCP connection.</t>


> # trying to figure out whether graceful shutdown at least during 'closing'
> state would ever be helpful.
>
> Thanks,
> - Yutaka
>
>
> hybi-bounces@ietf.org wrote on 02/15/2011 12:33:28 PM:
>
>
> > On 2/15/11 1:30 PM, Brian wrote:
> >
> > > If you need, with websocket, to detect that the user's gone
> > > away (such as for an IM system to show that they're offline), you can
> > > do that on the server when you detect the connection is closed.  If
> > > you're using xhr-polling or similar, a reasonably short timeout on the
> > > server during which the user doesn't reconnect for more data should
> > > suffice as a suitable "user has gone away" event.
> >
> > Agreed. And this is what we do in IM systems like XMPP (whether using
> > the TCP binding or BOSH).
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> >
> > [attachment "smime.p7s" deleted by Yutaka Takeda/R&D/SCEA]
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>