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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
