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