A question about ReplayingDecoder

[Nicholas Clare]

Hi,

I did check out the trunk, and it has indeed fixed the problem.
However, as per your advice, I'm currently rewriting my decoder to use
your method to read lines. I do have another question. The STOMP
protocol spec is pretty vague, and I'm not all that experienced with
it. In your HTTP code, it seems like you're assuming the headers are
ACSII text, since you're casting single bytes to chars. Obviously that
assumption is fine with HTTP, I'm not trying to suggest your code is
wrong.

In STOMP, however, they don't say anything like that anywhere, so I
figure it would be safer to try for UTF-8. So, where you put each
character into a StringBuilder, I'm using a ChannelBuffer (built by
ChannelBuffers.dynamicBuffer()), and only decoding the string at the
end (using ChannelBuffer.toString("UTF-8")). Does this seem like a
reasonable way to accomplish this?

Thanks,
Nick

On Wed, Apr 8, 2009 at 9:26 AM, Trustin Lee <tlee at redhat.com> wrote:
> The fix has been checked in: https://jira.jboss.org/jira/browse/NETTY-142
>
> Please pick up the nightly build in about 12 hours or build the trunk
> by yourself. :)
>
> HTH,
>
> — Trustin Lee, http://gleamynode.net/
>
>
>
> On Wed, Apr 8, 2009 at 3:38 PM, Trustin Lee <tlee at redhat.com> wrote:
>> Hi Nick,
>>
>> On Sun, Apr 5, 2009 at 9:02 PM, Nicholas Clare <nickclare at gmail.com> wrote:
>>> Hi all,
>>>
>>> As a learning excercise, I'm writing a decoder for the STOMP messaging
>>> protocol. After having a peek at the HTTP decoder in Netty, I was
>>> extremely impressed by the ReplayingDecoder class. It was a more
>>> powerful implementation of what I was planning to build myself.
>>
>> Thanks for the feed back.  I appreciate it! :)
>>
>>> Not wanting to just copy straight from the HTTP code, but rather learn
>>> myself, I came up with the following way to read a single line of text
>>> from the ChannelBuffer:
>>>
>>> String line = buffer.readBytes(LF).toString("UTF-8").trim();
>>>
>>> where LF is a static import from ChannelBufferIndexFinders. This works
>>> beautifully, *unless* the connection is terminated half way through a
>>> line. When that happens, a NoSuchElementException is thrown. At the
>>> moment, I'm overriding exceptionCaught() to check for the case where
>>> this exception is thrown, and the connection is no longer open, in
>>> which case I ignore the exception.
>>
>> This is a bug.  Here's an explanation:
>>
>> If a connection is not terminated, NoSuchElementException is not
>> raised at all because we never know the end of the buffer (i.e. LF
>> might appear at next read).  However, when a connection is closed,
>> suddenly we get to know where the buffer ends and therefore know if LF
>> exists or not.
>>
>> So, if a connection is closed and the buffer does not contain LF,
>> NoSuchElementException is raised.  This behavior is inconsistent and
>> ReplayingDecoder should not propagate NoSuchElementException to you
>> and ignore it silently.
>>
>>> So, my question is, supposing I do want to use the
>>> readBytes(ChannelBufferIndexFinder) method, is this the best way to
>>> get around the exception problem? Should I just put a try/catch around
>>> the code above, and if so, what should I do when I catch that
>>> exception? Just return null? Also, is the overhead of
>>> readBytes(ChannelBufferIndexFinder) high, and should I rather do it
>>> the way it's done in the HTTP code?
>>
>> readBytes(LF) is risky because it doesn't limit the length of the read
>> bytes.  For example, a malicious client could send 1 gigabyte stuff
>> without LF, then your server is in trouble.
>> readBytes(ChannelBufferIndexFinder) is not very useful when the size
>> of ChannelBuffer is infinite.
>>
>> If your application uses only LF-delimited messages, I'd suggest you
>> to use DelimiterBasedFrameDecoder.  Otherwise, I would use the way
>> done in the HTTP codec.
>>
>>> Thanks for all your help, and for the amazing Netty library,
>>
>> I hope my comments were helpful, and let me look forward to your
>> continuous feed back. :)
>>
>> — Trustin Lee, http://gleamynode.net/
>>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>