Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

[Pavel Rappo]

Simone,

> On 23 Jun 2016, at 14:48, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> I think you should not use the word "client" since it's not clear if
> you refer to the application or the implementation.
> Here it can be mistaken for both, but it's really the implementation.
> However, the readers of the Javadocs will mostly be application
> writers and would interpret it as the application.

Is this some kind of a clever sarcasm, designed to point out the ambiguity in
question? Because I actually meant the *application*. Consider the following
flow of events (let's assume a simplified scenario where all CFs from sendText
are returned already completed):

|->sendText("...", false);
|->sendText("...", false);
|<-onClose()
|->sendText("...", false); (A)
|->sendText("...", true);  (B)

onClose() has been received, but the application can still send messages until
the last chunk has been finally sent. Do you agree with this?

> I think this is wrong.
> Leaving room to "implementation specific" details is allowing for
> writing applications that are not portable.

We're talking about an extremely rare corner case, where we guarantee that a new
message WILL NOT be sent to the server. The difference is how the WebSocket will
react on attempting to do so.

Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS
will send a Close message instead and complete the CF returned from send
operation exceptionally.

> WebSocket's close mechanism is a double half close, like TCP.
> In TCP the semantic is very clear: sideA can half close, sideB can
> continue sending data, sideA will continue reading data, until sideB
> half closes.
> Same semantic in WebSocket.
> 
> WebSocket's onClose() is invoked when the server has half closed,
> similar to reading -1 from TCP.
> That only means that the server will not send more data.
> The client side could send data, and the server must receive it
> without problems.
> Once the client decides it's finished sending data, it will return
> from onClose(), and the implementation will send the reply close frame
> (if not already sent by the application).

I'm not a TCP expert. Does TCP allow an endpoint to skip the data it receives
after this endpoint has half-closed the connection? Because WebSocket does:

   ...However, there is no guarantee that the
   endpoint that has already sent a Close frame will continue to process
   data...

Thanks,
-Pavel