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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
