[OSC_dev] OSC compression (was: OSC bandwidth)

[Stephen Sinclair]

On Thu, Jul 17, 2008 at 1:28 PM, Andy W. Schmeder
<andy at cnmat.berkeley.edu> wrote:
> I am well aware that the O(1) overhead of the header can be a rather
> large fraction of the total in practice--but this depends greatly on
> the message, which is why for analysis it should be considered
> separately.  Incidentally, a compression strategy applied to OSC would
> likely approach this part of the protocol first--e.g. by using a
> lookup table of common strings.  Also, because OSC addresses are human-
> readable they are an obvious target for compression due to their low
> information-density (english being only ~1 bit per character).

I've had in mind for a while to try running a stream of OSC messages
over a TCP connection going through a gzip compression-decompression
on either side of the connection to see how well that would work.
However I haven't read up on whether or not gzip is the most
appropriate approach to compression of streams.  Has anyone tried
this?  Are there other compression algorithms better designed for
streaming data?  (In particular I'm imagining problems with an
ever-growing string table.)  I wonder how much CPU overhead it would
incur.  Maybe something extremely simple like run-length encoding
would even improve bandwidth.


Steve