[PD] tcpclient sending more than 1 send at once
IOhannes m zmoelnig
zmoelnig at iem.at
Tue Sep 9 14:56:04 CEST 2008
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:
> 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
[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
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?
More information about the Pd-list