[PD] tcpclient sending more than 1 send at once

[Roman Haefeli]

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!

roman




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