WebSocket

[Pavel Rappo]

> On 20 Feb 2018, at 23:49, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> I don't see why the message should be reassembled, given
> MessagePart.[FIRST|PART|LAST] ?
> It's not that the user can ask for the kind of MessagePart, e.g. ask
> only for WHOLE messages that the implementation must reassemble on her
> behalf, no ?
> So it will *always* be the case that zero copy is possible, right ?

Simone, this was said in the context of guaranteed receiving of WHOLE messages.
Initially we were talking about a possibility of providing buffering (i.e.
assembling/accumulating) in the implementation [1][2]. For partial messages
zero-copy is the case though [3].

I believe we have already decided we are not providing buffering in JDK 11. Your
example has clearly shown how conceptually simple it is to consume whole
messages on the user side, should the user need it. And unless the API changes
to hand a ByteBuffer[] instead of a single ByteBuffer, the user can process
whole messages more effectively (arguably, as there is still some overhead
because of creating instances of CompletionStage).

-Pavel

--------------------------------------------------------------------------------
[1] http://mail.openjdk.java.net/pipermail/net-dev/2018-February/011156.html
[2] http://mail.openjdk.java.net/pipermail/net-dev/2018-February/011171.html
[3] Just to keep it mind, it is only true until there are no extensions in the
    pre-defined maximum message size in the equation (RFC 6455):

       Unless specified otherwise by an extension, frames have no semantic
       meaning.  An intermediary might coalesce and/or split frames, if no
       extensions were negotiated by the client and the server or if some
       extensions were negotiated, but the intermediary understood all the
       extensions negotiated and knows how to coalesce and/or split frames
       in the presence of these extensions.