[PD] pd-extended crashes sending data to SSR with tcpclient
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.
More information about the Pd-list