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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list