1

I have read couple posts what makes the TCP packet gets fragmented. It seems to me it depends upon the MTU size - the request that exceeds the limit gets fragmented.

Here is my question regarding to Netty.

Assume that MTU size is 1500, and the request is 1000 bytes. Then, what the server's messageReceived() method receives is always exactly 1000 bytes in one shot or any chance it gets fragmented? I want to make sure the message that server receives is not fragmented.

If you think I am not understanding TCP or Netty well enough, then please point me to what I need to study?

I figured out my question is very similar to this. Dealing with fragmentation in Netty

What I want to double check is whether or not the fragmentation occurs even the request size is less than MTU limit. If yes, then I need the ReplayingDecoder.

Your suggestion is greatly appreciated.

Community
  • 1
  • 1
M.I
  • 173
  • 4
  • 17
  • For TCP the maximum segment size is more important than the MTU. The MTU is always larger than the maximum data TCP can put into a single TCP segment. See http://en.wikipedia.org/wiki/Maximum_segment_size . Unless you're in total control of the network infrastructure your app will run on, I would just deal with the possibility of fragmentation. At least that way it's guaranteed to work. If you know that all your requests are guaranteed to be a certain size, use FixedLengthFrameDecoder - http://static.netty.io/3.6/api/org/jboss/netty/handler/codec/frame/FixedLengthFrameDecoder.html – johnstlr Feb 07 '13 at 16:03
  • @johnstlr What you pointed out is EXACTLY what I wanted to know. I understood it is SAFE to deal with the possibility of fragmentations. Many Thanks! – M.I Feb 08 '13 at 02:08
  • @johnstlr Additional question. If the "Don't Fragment" under Flags in IP layer is set to 1, then there is no need to apply this "safety net?" Am I understanding correctly? – M.I Feb 08 '13 at 07:43
  • I've never tried it, and I don't think you can set it from within Java either. I believe you are correct in that your messages won't be fragmented but will be dropped if the network can't transport them. There's another issue here, and that's the size of the buffer Netty uses to read data from the socket. If it's too small Netty will return the data in multiple calls to messageReceived. You can set a ReceiveBufferSizePredictorFactory on bootstrap to be sure - see answer here http://stackoverflow.com/questions/8985389/java-netty-load-testing-issues – johnstlr Feb 08 '13 at 14:29
  • @johnstlr Actually, I do not think FixedLengthFrameDecoder works for my case since each request's message size differs (1st msg = 8 bytes, 2nd msg = 20 bytes, 3rd msg = 40 bytes). I could find several decoders but.. I have very hard time switching the buffer sizes. Could you please, suggest me what decoder I should use for such scenario? – M.I Feb 13 '13 at 08:17
  • That will depend on your protocol. For example, if each message is contains a length field specifying the length of the message you could use LengthFieldBasedFrameDecoder. If you can only tell if a message is complete by parsing it then you may need a custom FrameDecoder implementation. – johnstlr Feb 13 '13 at 10:34
  • @johnstlr Thank you so much for your support, again. I created custom FrameDecoder that reads the number of bytes it should receive from property file. I am not satisfied with this approach but it works for now. – M.I Feb 13 '13 at 12:17

1 Answers1

3

You may want to take a look at org.jboss.netty.handler.codec.replay.ReplayingDecoder. Here is a link to the online documentation: ReplayingDecoder

jdb
  • 4,419
  • 21
  • 21
  • Thank you jdb. I'll take a look. I am sure I will have more questions as I continue learning... – M.I Feb 07 '13 at 05:29