Thanks to Alexey's suggestion on moving to 2.0 & Connections, I
now have some experimental framework up and running based on the
LifeCycleExample demo.
My binary protocol is basically just a stream of TLVs; an id
byte, length of data, and the data itself... nothing special.
To separate out these discrete sets of bytes, in normal java/c I
just reconstruct each packet by first reading the length field
and reading the next n bytes to fill out the buffer, waiting for
the data if necessary....
Back to grizzly 2.0: I see that the processing stage starts at
handleRead... The ctx.getMessage() gets a Buffer of the next
set of bytes, but it is obviously not guaranteed to be a fully
constructed "message" as I would like it. It could be cut off,
queued up, etc.
What is the best "grizzly 2.0" way to cut up the incoming stream
into these logical packets of data, hopefully without editting
the grizzly internal classes? I guess I can just aggregate
these getMessage Buffers myself after the handleReads but in that
case I don't see a reason to use this framework with all the
overhead involved.
I think it would be helpful if you could show how to build upon
the example EchoFilter to only echo back lines of text. i.e.
'\n' would mark end of message, and a string would be the logical
unit. (so even from windows telnet it will only echo back on new
line, instead of on each character typed)
Regards,
-Emit