On 2012-02-16 13:26, IOhannes m zmölnig wrote:
On 02/16/12 19:16, Mathieu Bouchard wrote:
What is packet fragmentation and why is it preferable to take it into account even when not necessary ?
tcp/ip is a stream-based protocol and has no notion of "packets" like udp (which is a packet-based protocol).
meaning: if you send "1 2 3 4 5" this may be received as
- one block "1 2 3 4 5" OR
- two blocks "1 2" and " 3 4 5" OR
- two blocks "1 " and "2 3 4 5" OR
- six blocks "1", " 2 ", "3", " ", "4" and " 5" OR
- somehow else
no assumption must be made on how the data is fragmented on the receiver side". otoh, tcp/ip guarantees that data is received in order, so if you send to messages "1 2 " and "3 4 5" one after another, the resulting stream is guaranteed to be "1 2 3 4 5", wheras with UDP you might get "3 4 5" and "1 2 ".
therefore, if you want to be parse your data correctly, you must not assume that you get "1 2 3 4 5" as one message out of [tcpfoo]. instead you should parse the stream for some terminating sequence ";" or CRLF or whatever and re-packetize the stream.
it might only _seem_ to be "not necessary" in a given situtation, simply because you were observing some messages that came out correctly.
As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets.
Martin