Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

[Pavel Rappo]

Simone, please disregard the link to the test I gave you. My apologies. This
test has nothing to do with starting a new message after a Close message has
been received. It just verifies that the endpoint stops reading after receiving
onClose. So not sending back a Pong is perfectly natural in this case.

But I still think we probably more safe assuming the intersection of our
understandings, rather than a union :-)

> On 23 Jun 2016, at 16:20, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> 
>> On 23 Jun 2016, at 16:01, Simone Bordet <simone.bordet at gmail.com> wrote:
>> 
>> Hi,
>> 
>> However, here's another examples that shows the ambiguity:
>> 
>> |-> sendBinary(huge, true);
>> |<- onClose()
>> 
>> The implementation will fragment "huge", or the write will be
>> incomplete, so that "huge" is not fully sent yet.
>> When the onClose() is received, who is it that is sending the frames ?
> 
> The implementation. Sure.
> 
>> Certainly not the application, since the sendBinary() call returned.
>> It's the implementation that is sending the frames when onClose() arrives.
>> 
>>>> 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.
>> 
>> Why not ?
>> 
>>> 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.
>> 
>> Why you want to deny the possibility of sending data in half closed state ?
>> Implementation wise is simple, semantic is simple, is there a specific reason ?
>> 
>>> 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...
>> 
>> See, the sentence after that is:
>> 
>> "After both sending and receiving a Close message, an endpoint
>>  considers the WebSocket connection closed and MUST close the
>>  underlying TCP connection."
>> 
>> Which tells that an endPoint closes the TCP connection when it is
>> fully closed (2 halves).
>> So, if you *have* to continue reading from the network to read the
>> reply close frame, what do you do with the data that you read in
>> between ?
>> You throw it away ?
>> I guess that is "legal" too, but I would stay on the side of
>> reasonable behavior, not trying to literally adhere to a non-normative
>> vague wording.
> 
> Is that how it works in Jetty? Joakim has mentioned once his view on the correct
> behaviour here [1], which actually made me re-read the RFC and agree with him:
> 
>    ...Close should occur after the actively being sent message (aka once a
>    fin==true is encountered in the frame queue)...
> 
> Have a look at this testcase:
> 
>   http://autobahn.ws/testsuite/reports_20131013/clients/autobahnpypy_case_7_1_6.html
> 
> Interestingly enough, the Pong is not sent back. Yes, there's a variability in the test
> expected, but only in the amount of echoed text data, but they do not expect Pong.
> 
> Thanks,
> -Pavel
> 
> --------------------------------------------------------------------------------
> [1] http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009936.html
>