[PD] tcpclient sending more than 1 send at once

[IOhannes m zmoelnig]

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
> 
> 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.

i don't think that [packOSC] and [unpackOSC] should handle these.
the OSC-specs say: "The underlying network that delivers an OSC packet 
is responsible for delivering both the contents and the size to the OSC 
application."
[packOSC]/[unpackOSC] could be seen as the "OSC application" part, 
whereas [tcpsend]/[tcpreceive] could be seen as the "underlying network" 
part (or part thereof).

however, i _do not_ propose to add the length prefix to the 
[tcpreceive]/... part, as this will make it less useable in any other 
context.

personally i think it is a design flaw in OSC, to have stream-based 
transmission differently from package-based transmission.
claiming that the "underlying network" has to take care of it, is in 
contradiction to the claim of being "transport layer independent" (but 
then, the specs doesn't explicitely say so, and i probably just make it 
up myself; one could also argue, that OSC does not directly build on top 
of the transport layer and that there should be something inbetween OSC 
and the transport layer)

i think, the sending of "plain" OSC-messages should probably have been 
unsupported from the beginning, with eventually having a stripped down 
"bundle" that just has the message-length.

but anyhow, OSC has been around for quite some time, it's most likely 
useless to hope for a change.

as (imho) the re-packaging should be neither part of [unpackOSC] nor 
[tcpreceive], i would suggest using intermediate objects that handle the 
re-packaging of streams.
for now, zexy's [repack] should be able to do it.
on the long run: shouldn't Pd's [list]-family contain an 
atom-accumulator of this kind?


fmga,sdr
IOhannes