LengthFieldBasedFrameDecoder

Trustin Lee (이희승) trustin at gmail.com
Tue Sep 29 05:04:23 EDT 2009


You are welcome.  It does not matter you are good at English or not,
and your English is good enough already.  I'm not even a native
speaker - I've never stayed in English-speaking country for more than
a week in my entire life. :)

Please keep feeding us back with a good idea to improve Javadoc and
the user guide, as usual.

Cheers

-- Trustin Lee, http://gleamynode.net/

On Mon, Sep 28, 2009 at 1:06 PM, hezjing <hezjing at gmail.com> wrote:
> Hi Trustin and Netty contributors
> I have to clarify that English is not my native language and so the previous
> Javadoc could be good already.
> Thanks for updating the Javadoc and it is definitely clearer than before (at
> least to me).
> In overall, I appreciate the way Javadoc is maintained. I particularly like
> when there are some basic network details described in the Javadoc like the
> packet fragmentation described in FrameDecoder. These are indeed very
> helpful to novice network application developer.
>
> Thank you!
>
> 2009/9/25 Trustin Lee (이희승) <trustin at gmail.com>
>>
>> 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
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> 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