LengthFieldBasedFrameDecoder
Trustin Lee (이희승)
trustin at gmail.com
Thu Sep 24 21:49:23 EDT 2009
Here's the revised Javadoc:
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/handler/codec/frame/LengthFieldBasedFrameDecoder.java?r=1741
I'm sure it explains quite a lot about using LengthFieldBasedFrameDecoder now :)
Let me know if you have anything to add.
-- Trustin Lee, http://gleamynode.net/
2009/9/25 Trustin Lee (이희승) <trustin at gmail.com>:
> Hmm, I want the Javadoc to be easily understandable without referring
> to the source code. What would you suggest me to fix the
> documentation?
>
> -- Trustin Lee, http://gleamynode.net/
>
> On Wed, Sep 23, 2009 at 3:02 PM, hezjing <hezjing at gmail.com> wrote:
>> Yes, you're right.
>> I should really create a decoder with LengthFieldBasedFrameDecoder(0xFFFF,
>> 2, 2, 16, 0).
>> I was having problem figuring the correct lengthAdjustment until I found the
>> formula from the LengthFieldBasedFrameDecoder source code:
>> frameLength += lengthAdjustment + lengthFieldEndOffset;
>>
>> Again, thanks for your help!
>>
>> On Mon, Sep 21, 2009 at 2:45 PM, Trustin Lee (이희승) <trustin at gmail.com>
>> wrote:
>>>
>>> Not actually. It is supposed to work with either cases, as there are
>>> lengthAdjustment and initialBytesToStrip.
>>>
>>> initialBytesToStrip should be 0 because you don't want the resulting
>>> frame's header stripped out.
>>>
>>> lengthAdjustment could be 20 or something close to it because there's
>>> an extra data between the length field and the payload.
>>>
>>> The Javadoc says:
>>>
>>> "It is particularly useful when you decode a binary message which has
>>> an integer header field that represents the length of the message body
>>> or the whole message."
>>>
>>> which means, it works regardless whether the length field includes the
>>> header or not. Am I missing something? Could you suggest where to
>>> improve?
>>>
>>> -- Trustin Lee, http://gleamynode.net/
>>>
>>>
>>>
>>> On Mon, Sep 21, 2009 at 3:24 PM, hezjing <hezjing at gmail.com> wrote:
>>> > Hi Trustin
>>> >
>>> > In my case, the length field is the size of the payload (excluding the
>>> > header).
>>> >
>>> > If I read the Javadoc correctly, the LengthFieldBasedFrameDecoder is
>>> > applicable when the length field is the size of the header and payload
>>> > right?
>>> >
>>> > :-)
>>> >
>>> > On Mon, Sep 21, 2009 at 9:39 AM, Trustin Lee (이희승) <trustin at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi Hez,
>>> >>
>>> >> Thanks for closing this thread with a good answer and sorry that I'm
>>> >> late.
>>> >>
>>> >> Do you find the Javadoc of LengthFieldBasedFrameDecoder difficult to
>>> >> understand? I thought your use case is explained already there. Let
>>> >> me know what you think so that we can improve the documentation.
>>> >>
>>> >> Cheers
>>> >>
>>> >> -- Trustin Lee, http://gleamynode.net/
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Sep 20, 2009 at 9:12 PM, hezjing <hezjing at gmail.com> wrote:
>>> >> > Hi Mike
>>> >> > Hmmm ... do you mean the example of the frame like the following?
>>> >> > <-- HEADER 20 bytes --><-- PAYLOAD 14 bytes -->
>>> >> > +-------+---------+----+-----------------------+
>>> >> > | | Length | | Payload |
>>> >> > | | 0x000C | | |
>>> >> > +-------+---------+----+-----------------------+
>>> >> > Total frame size is 34 bytes.
>>> >> > <-- HEADER 20 bytes --><-- PAYLOAD 100 bytes -->
>>> >> > +-------+--------+-----+------------------------+
>>> >> > | | Length | | Payload |
>>> >> > | | 0x0064 | | |
>>> >> > +-------+--------+-----+------------------------+
>>> >> > Total frame size is 120 bytes.
>>> >> >
>>> >> >
>>> >> > On Sun, Sep 20, 2009 at 1:41 AM, Mike McGrady
>>> >> > <mmcgrady at topiatechnology.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Could you include an example write with this? The two together, I
>>> >> >> suspect, will be most helpful to many people, including me.
>>> >> >> Mike
>>> >> >> On Sep 19, 2009, at 8:11 AM, hezjing wrote:
>>> >> >>
>>> >> >> Hi
>>> >> >> To close this thread, my solution is to extends FrameDecoder like
>>> >> >> the
>>> >> >> following code:
>>> >> >> @ChannelPipelineCoverage("all")
>>> >> >> public class MyFrameDecoder extends FrameDecoder {
>>> >> >> @Override
>>> >> >> protected Object decode(ChannelHandlerContext ctx, Channel
>>> >> >> channel,
>>> >> >> ChannelBuffer buf) throws Exception {
>>> >> >> // the length field is at 3rd and 4th octet
>>> >> >> if (buf.readableBytes() < 4) {
>>> >> >> return null;
>>> >> >> }
>>> >> >> // The length field is in the buffer.
>>> >> >> buf.markReaderIndex();
>>> >> >> ...
>>> >> >> // Read the length field (the payload size)
>>> >> >> int length = buf.readUnsignedShort();
>>> >> >> // The actual frame size is header (20) + payload size
>>> >> >> length += 20;
>>> >> >> buf.resetReaderIndex();
>>> >> >> if (buf.readableBytes() < length) {
>>> >> >> return null;
>>> >> >> }
>>> >> >> ChannelBuffer frame = buf.readBytes(length);
>>> >> >> return frame;
>>> >> >> }
>>> >> >> }
>>> >> >>
>>> >> >> Thank you!
>>> >> >>
>>> >> >> On Thu, Sep 10, 2009 at 9:23 PM, hezjing <hezjing at gmail.com> wrote:
>>> >> >>>
>>> >> >>> Hi
>>> >> >>> I have a message containing a fixed length header of 20 bytes,
>>> >> >>> followed
>>> >> >>> by a payload of variable length.
>>> >> >>> The header contains a 2 bytes length field, indicating the length
>>> >> >>> of
>>> >> >>> the
>>> >> >>> payload (excluding the header).
>>> >> >>> For example if the message has 10 bytes payload, then the entire
>>> >> >>> frame
>>> >> >>> length is 30 bytes (20 bytes header + 10 bytes of payload),
>>> >> >>> and the length field is 10.
>>> >> >>> May I know what is the parameter to
>>> >> >>> create LengthFieldBasedFrameDecoder?
>>> >> >>>
>>> >> >>> Thank you!
>>> >> >>>
>>> >> >>> --
>>> >> >>>
>>> >> >>> Hez
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >>
>>> >> >> Hez
>>> >> >> _______________________________________________
>>> >> >> netty-users mailing list
>>> >> >> netty-users at lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/netty-users
>>> >> >>
>>> >> >> Mike McGrady
>>> >> >> Principal Investigator AF081-028 AFRL SBIR
>>> >> >> Senior Engineer
>>> >> >> Topia Technology, Inc.
>>> >> >> 1.253.720.3365
>>> >> >> mmcgrady at topiatechnology.com
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> netty-users mailing list
>>> >> >> netty-users at lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/netty-users
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> >
>>> >> > Hez
>>> >> >
>>> >> > _______________________________________________
>>> >> > netty-users mailing list
>>> >> > netty-users at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/netty-users
>>> >> >
>>> >> >
>>> >>
>>> >> _______________________________________________
>>> >> netty-users mailing list
>>> >> netty-users at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/netty-users
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Hez
>>> >
>>> > _______________________________________________
>>> > netty-users mailing list
>>> > netty-users at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/netty-users
>>> >
>>> >
>>>
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>>
>>
>> --
>>
>> Hez
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>>
>
More information about the netty-users
mailing list