This is unnecessary, as the the RFC 6455 message has no overall length.
Each RFC messages is made up of [1..n] RFC fragments, and those fragments
do have a size indicator.
With the getSendWriter and getSendStream you'll have to follow the same
semantics as in the servlet-api:
1) There should only ever be 1 active "message stream" at any time.
a) And unlike the servlet-api, when the prior stream is released via
the .close() operation, another stream is now allowed to be fetched.
b) An attempt to get another "message stream" from the RemoteEndpoint
should result in an IllegalStateException to the end user
c) Non data opcodes like ping/close should be allowed in the middle of
an active "message stream"
2) Each .write() operation should queue up into an internal buffer
(implementation specific size)
a) When the internal buffer is full, it should auto-flush
3) Each called .flush() operation should commit the data out to the network
layer.
a) Each flush is a 1..n RFC fragments
b) First fragment is the opcode of the stream type.
c) Each following fragment is the opcode of type CONTINUATION
4) The .close() operation should flush and send the final FIN=true fragment.
a) Note that it is possible to have a final close with no pending
outgoing data, send a 0 length fragment with FIN=true in this situation
b) If the internal buffer has never been sent, send it now, with
FIN=true and opcode of the message type.
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Fri, Feb 8, 2013 at 1:28 AM, Norman Maurer <nmaurer_at_redhat.com> wrote:
> Hi all,
>
> while working on my implementation of RemoteEndpoint I encountered a few
> issues. Well not really issues but a few things I would like to start a
> discussion about..
>
> Most important I wonder why RemoteEndpoint.getSendWriter() and
> getSendStream() don't take a payload size as argument. The problem at the
> moment is that the whole message needs to be buffered till the close()
> method was called. This is because the length of the message (websocket
> frame) is encoded in the "header" of the message (at least for all the
> versions > 00) . So without knowing the size up-front it is not possible to
> start the transfer as it needs to get calculated from the whole message. I
> think this is very inefficient and can result in a lot of memory usage on
> the implementation, as the user may send a very big message. If the method
> signature would be changed to take the payload size it would be possible to
> directly start the transfer of the message and send data in "chunks" over
> the wire.
>
> Feedback welcome…
>
> Cheers,
> Norman
>
> ---
> Norman Maurer
> nmaurer_at_redhat.com
>
> JBoss, by Red Hat
>
>
>
>