users@grizzly.java.net

Some questions about the ProtocolParser interface

From: Erik Svensson <erik.svensson_at_six.se>
Date: Thu, 07 Feb 2008 16:03:42 +0100

Howdy all!

I'm currently implementing a protocol parser and looking at the java doc for
the interface some questions comes up.

I'm a bit unclear about the contract implicit in the ProtocolParsers
interface. If we start from the start, with startBuffer() (:-)) it's almost
clear. It basically states that the ByteBuffer parameter is a byte source to
be parsed. It's also stated that startBuffer() 'should store the buffer and
its state so that subsquent calls to getNextMessage() will return distinct
messages'. I take this to mean that the contents of the source should be
appended or added to some ProtocolParser local storage (in my case appended
to a local ByteBuffer). However releaseBuffer() states that 'No more parsing
will be done... . Set up the buffer so that its position is the first byte
that was not part of a full message'. This indicates that the full content
of the source meantioned above should NOT be copied into local storage when
the startBuffer() method is invoked. releaseBuffer() also states
'[Returns] true if the parser has saved some state [in the source buffer]'
which contradicts the documentation from startBuffer(). There is also a
problem with this. Unless framework is ready to grow the source buffer
(which it is not according to some mails on the list) this might be a
problem. Some clients send large messages (I know of one protocol where the
messages can be arbitrarly large. In one case the message was 21 MB.). Since
it's bad to make assumptions about the frameworks behaviour (which might
change at the drop of a hat) the protocol parser has to keep state itself
(and store all incoming bytes). Ie, I think releaseBuffer() should work as
'be done with this buffer'-message from the ParserProtcolFilter.

getNextMessage() is another puzzle. The first sentence 'Get the next
complete message from the buffer, which can then be processed by the next
filter in the protocol chain.' I understand as ' Get the next complete
message from the buffer, parse it to non-byte format and pass it on to be
processed by the next filter in the protocol chain'. However, the next
sentence makes no sense to me: ' Because not all filters will understand
protocol messages, this method should also set the position and limit of the
buffer at the start and end boundaries of the message'. Does this mean that
the ProtocolParser should NOT consume the bytes in the buffer? Isn't the
point of all this to turn a stream of bytes into a buffer? Further, if the
ProtocolParser has stored bytes locally then the buffer is full of data that
makes no sense without the locally stored data and might not even make sense
with that data as the message might not be complete.
In that vein, when you add filters to the protocol chain, can you assume
that they will invoked in the order added?

This is a bit rambling as I try to work while writing it but I would really
like to see a bit of idea beyond the tutorial on how this is supposed to
work.

Also, the javadocs is bit old.In the comments to hasMoreBytesToParse() the
method 'parseBytes()' is mentioned. parseBytes() cannot be found however, so
I'm guessing getNextMessage() is what's meant.
There's a bunch of others.