[PD] bi-directional OSC over TCP from liblo
reduzent at gmail.com
Sat Nov 10 11:24:45 CET 2012
On Fre, 2012-11-09 at 17:19 +0100, IOhannes m zmölnig wrote:
> On 11/09/2012 02:51 PM, Jamie Bullock wrote:
> > So, it seems like [packOSCstream] and [unpackOSCstream] are (un)packing message in a format that can't be used with external clients/servers. Is that correct?
> from your experience with liblo, you seem to conclude that:
> a) all "external clients/servers" are build on top of liblo.
> b) liblo handles OSC over TCP/IP correctly
> c) [(un)packOSCstream] handles it wrongly.
> originally OSC did not define how to transmit OSC-packets over a
> stream-based protocol like TCP/IP (that has no notion of ending packets).
> implementations that wanted to transmit OSC over stream-based protocols
> had to find solutions for themselves.
> a few years ago, the OSC specs have been extended, to explicitely
> mention "SLIP" encoding as the means to packetize streams of OSC-data.
This was added to OSC 1.1, iirc.
OSC 1.0 proposed to prepend to each OSC packet a 4 byte header that
contains the byte count of following OSC packet. Old versions of
[packOSCstream]/[unpackOSCstream] implemented this proposal.
The 4-byte-header has the big disadvantage of once being out-of-sync, it
never catches up again. One would have to re-establish the connection
> [packOSCstream] implements this standard by use of [slipenc].
Exactly, in order to comply with OSC 1.1 (and while breaking
compatibility with OSC 1.0)
I don't know liblo so well, but you might want to check if it is using
the 4-byte-header for OSC-over-TCP.
More information about the Pd-list