On 2012-02-16 16:38, Roman Haefeli wrote:
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).
The [mrpeach/tcp*] classes don't make any assumptions about content,
they just output lists of floats as they arrive. It seems more efficient
to do that than to output individual floats. Whatever is handling the
output of a [tcp*] should be able to decide for itself where the packet
boundaries are. I don't assume that a list is necessarily the same
length as a packet.
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.
You can get multiple user-packets inside one TCP or UDP packet, but I
have never seen a small one broken in two. For an http reply the web
page can arrive spread over several packets, and the connection closes
when all the packets are in. I don't have any problems with those.
It can be interesting to use Wireshark to look at what's actually in the
packets.
Martin
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
