[OSC_dev] OSC Questions regarding Protocol

[Adrian Freed]

>Content-type: multipart/alternative; boundary=--43278a5638ac49906cce
>Content-language: en
>
> > OSC avoids the end-to-end principle by design.
>>
>> For efficiency discussions also note that OSC generally assumes
>> a 32-
>> bit architecture, thus the 4-byte alignment saves instruction
>> cycles 
>> and costs no additional memory.  This isn't explained
>> explicitly in 
>> the specification but is the reasoning behind that decision.
>
>Where encoding efficiency matters is wireless.  Every bit costs energy to transmit, and the more data that is transmitted the greater the chance that part of the message will need to be retransmitted due to noise - increasing latency and jitter.  Admittedly bandwidth will improve when we move to the 5 GHz plus bands, but bits will still cost energy to transmit, and more battery life is always better than less.   Most of the  energy  consumed by a  small wireless device goes to transmitting bits.  The more bits transmitted, the closer battery life is is to being proportional to the amount of data transmitted.
> 
>For the devices I am developing I elected to develop a compact serial protocol that I use over USB and will use over wireless, and I have developed a driver/gateway that converts this to and from OSC on a host computer.  My protocol transmits the same information in less than 20% of the space.

Good solution.

It is quite easy to achieve such speedups in a general way with OSC. Here are two recipes. Both of them nibble away at the advantage OSC has of statelessness but with care in a way that is not too intrusive on usability:

1) Since most of the OSC address strings are static: client and host decide on a perfect hashing function and encode as many address strings as 3-characters and a null.
2) Since many OSC packets have the same structure with only the data values change, repackage all the data values in a single blob with a server-side cache of the actual structure. Invalidate or grow this cache when the packet structure changes.

We use variants of the latter strategy quite often to push values from I/O hardware thru OS interfaces to the application.

Note that on-the-fly compression is built into web standards and the upcoming binary XML standards to address this efficiency issue . I can imagine when this matures picking a recommendation or even a standard for OSC along these lines.