[PD] socket object?

[Martin Peach]

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