Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

[Pavel Rappo]

> 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