[PD] tcpclient sending more than 1 send at once

[Martin Peach]

Claude Heiland-Allen wrote:
> Martin Peach wrote:
>> The idea is to expand it to fit circumstances as they arise. I hadn't 
>> really tried OSC over TCP, so I wasn't aware of this problem. I agree it 
>> needs fixing, I'm just not sure of the best way at the moment. It could 
>> be simpler to prefix the OSC packet with its length.
> 
> That's indeed what is recommended by the OSC specification for 
> stream-based protocols:
> 
> http://www.nabble.com/Questions-wrt--OSC-implementation-details.-td1109673.html
> 

Yes the spec says:
"
In a stream-based protocol such as TCP, the stream should begin with an 
int32 giving the size of the first packet, followed by the contents of 
the first packet, followed by the size of the second packet, etc.
"
(http://archive.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html)

> But this makes it more complicated, [packOSC] and [unpackOSC] would need 
> to know whether the data should be sent or is being received from a 
> packet-based protocol or a stream-based protocol, to know whether to 
> prefix the length or not.

The length could be added and removed in between, at the expense of a 
bunch of list objects (which would work right now), or else [packOSC] 
and [unpackOSC] could have creation arguments to specify the use of a 
length prefix (which will take a little while to implement).
Both are easier than rewriting [unpackOSC] to work with unknown packet 
lengths, which seems silly since the length _is_ known at the sender and 
the overhead of sending four more bytes is minimal.

Martin