Hi Martin
On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote:
On 02/16/12 19:39, Martin Peach wrote:
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.
I think, this is a misconception. As IOhannes pointed out, TCP is a _serial_ protocol. No assumption can be made about the underlying transport. You don't know if an IP packet size can be guaranteed trough the whole path. It might well be, that the at some point the IP packets are broken down in smaller packets. Also the opposite happens easily: When the application sends many small chunks in short time, the network stack might glue them together and put them into one IP packet. There is no way you can take them apart on the receiving side. Also, the application protocols I know that are built on-top of TCP use all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I don't know of any protocol, that relies on the chunks keeping their size over transport for delimiting messages. Using TCP chunks as a way of delimiting is wrong and should not be promoted (as it is done by the [mrpeach/tcp*] classes).
nevertheless, in practice you are right that you will experience problems more easily with large IP packets, and smallish ones (like the ones we were originally talking about) might hardly ever be effected.
No, also the smallish ones are affected. See above. I experienced that with Pd.
Roman