Netty : does it need to care TCP segments reassembly?

3
votes

I have a question regarding to TCP segments reassembly. I learned the packet could be devided into multiple segments (this is something to do with MSS).

i.e) Message flow (Assumption):

  1. Client sends a packet that is passed from application layer
  2. In client side's TCP layer, the packet divided into 3 segments.
  3. the segments passed to Client's IP layer.
  4. the Server's IP layer receives the segments.
  5. In server side's TCP layer, it receives the 3 packets and reassembles it as one packet.
  6. Server's application layer receives the one packet.

My understaning is that TCP layer is where the divided segments get reassembled. Correct me if I am wrong.

Here is the thing what I really want to clarify.

When using Netty, Server side's "messageReceived()" method gets called only one time or 3 times? If the TCP layer is the place where the divided segments gets reassembled, the "messageReceived()" method gets called only once, correct?

Then, is it really neccesarry to use something like "ReplayingDecoder" to guarantee the number of bytes server is receiving?

Your help is greatly appreciated.

Additional Question:

If the server fails to reassemble the segments because one of them is lost or something, then the TCP layer pass the incomplete packet to the application layer?

1
socketstcpnettynio
It should get done in the TCP layer. Have a look at the sliding window protocol for more information on how this happens. – slugonamission
@slugonamission Thank you. I had a weak understanding about the fact "sliding window" is used for the segment reassembly. So, I can assume that Server side's "messageReceived()" method gets called only once? – M.I
It should be. Remember that this should form a stack, so layer 3 should be a black box (in reality, it rarely is) with a sendData and recvData interface. Layer 4 should not care whatsoever how the data is split and transmitted (and equally, layer 3 should be able to be seamlessly replaced with another similar block without any code changes). The OSI model is there such that each layer shouldn't need in-depth knowledge of other layers. – slugonamission
@M.I TCP takes care of TCP segmentation. That's nothing you need to worry about. However, TCP does not present you, the programmer, with an interface to send packets. TCP gives you a byte stream, much like a normal file. If your application sends packets/messages meaningful to your application, you need some way to receive one full such message - and simply calling a receive function on a TCP socket might give you just 1 byte of data. Or 16kbyte of data (if your receive buffer is that big.) You need a way to carve your own messages out of that stream, much as you would reading them from a file – nos
@slugonamission The sliding window protocol is only weakly related to segment reassembly, and not at all to packet reassembly, and there is no guarantee whatsoever about how many reads will be necessary. – user207421

1 Answers

3
votes

the packet could be divided into multiple segments

Upside down, or bad terminology. TCP sends segments which are divided into packets and which may be further split into sub-packets en route.

My understanding is that the TCP layer is where divided segments get reassembled.

Packet reassembly takes places in the IP layer, not the application (or the TCP layer). Segment reassembly takes place in the TCP layer.

"messageReceived()" method gets called only one or 3 times?

It gets called any number of times from 1 to N where N is the length of the byte stream. There is no guaranteed 1::1 correspondence between sender sends and receiver receives.

If the server fails to reassemble the segments because one of them is lost or something, then the TCP layer pass the incomplete packet to the application layer?

Absolutely not. TCP doesn't pass packets to the application layer at all. It passes an intact, correctly sequenced byte stream, or nothing.

Wondering if i should handle the segment reassembly by myself

You don't, and can't, handle any of it yourself. TCP provides a byte stream to the application, not segments or packets.