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