[PD] socket object?

[Martin Peach]

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