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