[PD] pd-extended crashes sending data to SSR with tcpclient

[Martin Peach]

On 2013-07-02 16:13, Roman Haefeli wrote:
> On Die, 2013-07-02 at 17:07 +0200, Matthias Geier wrote:
>> Hi Iain.
>>
>> To be honest, I didn't think about the problem that a message could
>> need more than one packet.
>> It's good to know that iemnet/tcpclient can handle that.
>
> It's not that [iemnet/tcpclient] can handle it and [net/iemnet] can't.
> In fact, with both you have to cook your own mechanism to delimit
> packets for a packet oriented protocol. With [net/iemnet], however, you
> have to serialize the data first in order to be able to do that. I see
> two problems with [net/tcpclient]'s implementation:
>
>   * you have to serialize the data anyway, so why doesn't the object
>     already do it?
>

I think I implemented it that way because it seems to be more efficient 
within Pd to deal with a single list rather than a bunch of floats.
But I don't know for sure if that is true.

>   * It gives you the false impression of dealing with packets when you in
>     fact are dealing with a stream. It's dangerous because it often looks
>     as if it would be working, but there is no guarantee it will always
>     do. You may receive a packet split into many chunks, or you get a
>     big chunk containing several packets. All those cases are valid from
>     to POV of TCP, but will break your protocol unless you deploy proper
>     delimiting.

Well the TCP protocol _is_ splitting a stream into packets. It's not the 
same as a serial link where you can send bytes one at a time whenever 
you like. If you try that you will find that the bytes are gathered into 
packets for you. It might be useful to consider this when thinking about 
the best way to send the data (e.g. one byte per packet is not 
efficient, and you might get the false impression that TCP doesn't work 
very well).

And as I always say, UDP is probably a better choice for what you are 
trying to do, if it involves real-time control, with UDP you _do_ have 
control over the packet size.

Martin