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

Roman Haefeli reduzent at gmail.com
Wed Jul 3 00:49:24 CEST 2013


On Die, 2013-07-02 at 18:15 -0400, Martin Peach wrote:
> 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.

Yeah, this is what I assume as well, though I don't have any data to
back up that assumption. On the other hand, serializing might be cheaper
on the C side than in Pd. I just cannot think of a use case where you
actually want to directly use those chunks as received. Either you need
to delimit packets, then you need to serialize the data, or you actually
need a stream, but then you also need to serialize the data. 

> >   * 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).

Since the TCP stack is free to packetize the data in the most efficient
way, the application layer does not have to, or even _must_ not consider
chunk size of data. This should be handled transparently by the
transport layer. When the application transmits thousands of 1-byte
chunks, the TCP layer will most likely send them as bigger chunks over
the network. From the application's point of view, TCP is _exactly_
behaving like a serial link (just without a clock). 

> 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.

Agreed.

Roman







More information about the Pd-list mailing list