Re: [hybi] Clarify the role of closing handshake

Takeshi Yoshino <tyoshino@google.com> Sat, 12 February 2011 00:17 UTC

Return-Path: <tyoshino@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 6597C3A69D1 for <hybi@core3.amsl.com>; Fri, 11 Feb 2011 16:17:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.293
X-Spam-Level:
X-Spam-Status: No, score=-105.293 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 2gURha3uNdvA for <hybi@core3.amsl.com>; Fri, 11 Feb 2011 16:17:52 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id ADBB23A6A24 for <hybi@ietf.org>; Fri, 11 Feb 2011 16:17:51 -0800 (PST)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p1C0I695032764 for <hybi@ietf.org>; Fri, 11 Feb 2011 16:18:07 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297469887; bh=rAg/V+0jF0il7d9UUipZ32FYY5g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IQi7szgcoODXlu+i9z5/ERqH+utePD6sRPJHBVphpx3WUbM/SbaUHXgJ7e1qlykJb nK9MLmFjxLCJ1aKDBrtXg==
Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by kpbe19.cbf.corp.google.com with ESMTP id p1C0I5xr015228 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Fri, 11 Feb 2011 16:18:05 -0800
Received: by gxk8 with SMTP id 8so1405997gxk.41 for <hybi@ietf.org>; Fri, 11 Feb 2011 16:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DtgghnXGS7IyCQcLMtHcQdHAoIqNgaxNJZf7LAoEg3U=; b=TVvMr1euo4BgepMWyz80DyoLs811NRvZkR58/rGrvgXrRhfGEAfVkM4mfZUTTdELHp fz0f1GnYi7UxmsbBGLDA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=IUxSpB3bBBtxA3xsnQcu+C7lI68gy6iFOP84dYcX4vBIPxdemzBzsB8TzBoUkwlGyw O/BrG3vx/75YcSzftdqA==
Received: by 10.151.26.18 with SMTP id d18mr1357101ybj.48.1297469884921; Fri, 11 Feb 2011 16:18:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.91.16 with HTTP; Fri, 11 Feb 2011 16:17:44 -0800 (PST)
In-Reply-To: <OF4A78F456.78EA8086-ON88257834.00735B16-88257834.0074BBCC@playstation.sony.com>
References: <OFAAD26076.80417033-ON88257834.006C2055-88257834.0072D42E@playstation.sony.com> <OF4A78F456.78EA8086-ON88257834.00735B16-88257834.0074BBCC@playstation.sony.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 11 Feb 2011 16:17:44 -0800
Message-ID: <AANLkTimizRk+73rHJcw16JdWwM8Ax9dhpUqNxEdPLyL4@mail.gmail.com>
To: Yutaka_Takeda@playstation.sony.com
Content-Type: multipart/alternative; boundary="000e0cd6a87898f871049c0abff6"
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
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: Sat, 12 Feb 2011 00:17:53 -0000

Hi Yutaka,

Thank you for joining the discussion.

Good point. I know that close(2) with incoming data remaining unread in
kernel causes RST for example on Linux. It looks like this is very platform
dependent.

Let me confirm your claim. Here, you mean that RST coming after PSH(Close
frame octets) may cause trouble the receiver side in recv-ing Close frame
octets? In a bit different context but I see that Jamie is also saying so
in http://www.ietf.org/mail-archive/web/hybi/current/msg01044.html. On what
platform this really occurs for example? Just curious. Linux socket allows
us to recv data PSH-ed before RST, then ECONNRESET is returned, so I missed
this point.

If we still take the way to drop Close reply,
- Just as a hint for intermediaries to know the session is abandoned earlier
than transport layer phenomenon (as Gabriel first suggested), it's still
worth try to send out Close and let intermediaries see it, I think. We don't
have to make it sure that it's seen by intermediaries or delivered to the
other peer.
- If we decide to let a Close frame carry error code (as Greg and Brodie
suggest), yes, it may be problematic that Close frames are dropped even
though there's no network/intermediate problem.

Let's go through again what each case means,
- received abnormal Close frame means there was any protocol level problem
- received normal Close frame means the other peer is satisfied. this never
means data is delivered
- didn't receive Close means (?)
-- because of RST issue
-- because of network issue

We have to give (?) some semantics that's not confusing.
- (?) := "there was network layer error" : this statement is bad, confusing.
application that frequently exchanges data may suffer RST issue, and retry
though it's actually caused by their own traffic.
- (?) := "there was transport layer error" : still not so clear
- (?) := ... any suggestion?

On Fri, Feb 11, 2011 at 13:15, <Yutaka_Takeda@playstation.sony.com> wrote:

>
> Let me correct some typo in the diagram:
>
>
> [App]          [WS-layer]     [TCP socket]
>
>  |    close()     |               |
>  +--------------->|  send(Close)  |<--- data
>  |<- - - - - - - -|-------------->|
>  |                |  shutdown(WR) |<--- data
>  |                |-------------->| ----> FIN
>  |                |  * recv()     |<--- data
>  |                |till EOS(0 rtn)|
>  |                |-------------->|
>  |                |    close()    | <--- FIN
>  |                |-------------->x
>  |                |               :
>
>
> # It's not so simpler after all, is it? :)
>
> This is what it takes to send 'data'(in this case 'Close frame'  to peer
> right before
> closing TCP connection.
>
> If this is too complicated, then don't bother sending 'Close' but just
> close TCP socket,
> which would be the simplest. My preference is to do above cleanup properly.
>
>
IIRC, there was discussion in designing -00 closing handshake that we should
avoid underlying transport layer's semantics in realizing WebSocket layer
event. To follow this philosophy, we could replace the last FIN with Close
frame. i.e. we again ask both sides send a Close frame so that both sides
can safely invoke close(2) after seeing Close frame.

...snip


> > As long as we cannot rule out the case where there may be incoming
> > data in the TCP buffer at the time of Close frame send, the endpoint
> > should not close socket right away, otherwise TCP-RST is sent to the
> > peer, and the Close frame that has just sent may not reach the
> > remote app. So, WebSocket layer needs to take care of this cleanup
> > sequence:
> >
> > [App]          [WS-layer]     [TCP socket]
> >   |    close()     |               |<--- data
> >   +--------------->|  send(Close)  |<--- data
> >   |<- - - - - - - -|-------------->|----> FIN
> >   |                |  * recv()     |<--- data
> >   |                |till EOS(0 rtn)|
> >   |                |-------------->|
> >   |                |    close(|    |
> >   |                |-------------->x
> >   |                |
> >
> > This is an implementation issue, but worth mentioning.
> >
>

...snip