Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
IP Message Reassembly Process
(Page 2 of 2)
The Reassembly Process
As we saw in looking at how
fragmentation works, it involves a fair
bit of complexity. Several IP header fields are filled in when a message
is fragmented to give the receiving device the information it requires
to properly reassemble the fragments. The receiving device follows a
procedure to keep track of the fragments as they are received and build
up its copy of the total received message from the source device. Most
of its efforts are geared around dealing with the potential difficulties
associated with IP being an unreliable protocol.
The details of implementation of
the reassembly process are specific to each device, but generally include
the following functions:
- Fragment Recognition and Fragmented Message
Identification: The recipient knows it has received a message fragment
the first time it sees a datagram with the More Fragments bit
set to one or the Fragment Offset a value other than zero. It
identifies the message based on: the source and destination IP addresses;
the protocol specified in the header; and the Identification
field generated by the sender.
- Buffer Initialization: The receiving device
initializes a buffer where it can store the fragments of the message
as they are received. It keeps track of which portions of this buffer
have been filled with received fragments, perhaps using a special table.
By doing this, it knows when the buffer is partially filled with received
fragments and when it is completely full.
- Timer Initialization: The receiving device
sets up a timer for reassembly of the message. Since it is possible
that some fragments may never show up, this timer ensures that the device
will not wait forever trying to reassemble the message.
- Fragment Receipt and Processing: Whenever
a fragment of this message arrives (as indicated by it having the same
source and destination addresses, protocol and Identification
as the first fragment), the fragment is processed. It is inserted into
the message buffer in the location indicated by its Fragment Offset
field. The device also makes note of the fact that this portion of the
message has been received.
Reassembly is finished when the entire
buffer has been filled and the fragment with the More Fragments
bit set to zero is received, indicating that it is the last fragment
of the datagram. The reassembled datagram is then processed like a normal,
unfragmented datagram would be. On the other hand, if the timer for
the reassembly expires with any of the fragments missing, the message
cannot be reconstructed. The fragments are discarded, and an ICMP
Time Exceeded message generated. Since
IP is unreliable, it relies on higher layer protocols such as TCP to
determine that the message was not properly received and then retransmit
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.