Hi,
On Thu, Jun 23, 2016 at 4:09 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote:
> Is this some kind of a clever sarcasm, designed to point out the ambiguity in
> question?
Nope.
> 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?
Sure.
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 ?
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.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
