[PD] tcpclient sending more than 1 send at once

Roman Haefeli reduzierer at yahoo.de
Tue Sep 9 15:06:26 CEST 2008

On Tue, 2008-09-09 at 08:41 -0400, Martin Peach wrote:
> 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)

thanks for pointing this out, claude and martin. this makes the whole
story a _lot_ easier.

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

agreed. i am very happy about any simple solution as long as it meets
the OSC specification. i missed, that the OSC specs mention transport
over stream-based protocols separately. as you said, it is even so easy,
that it could be implemented in plain pd. i even think now, that
[packOSC]/[unpackOSC] should stay untouched, because from the specs they
do exactly what they are supposed to do (encoding / decoding OSC
packets), while the frame length seems to be something additional, that
is only needed for stream based transport. shouldn't that be called
another layer? 

i think, i am going to do the frame length part myself. for me the
problem is solved (i don't need anyone to change any code). thanks!


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list