True that OSC, because it is unsecure, it must be encapsulated with
encrypted protocols (if required). For creative use cases on web sites
(or single page apps), WebSocket (or WebRTC) is used to transmit (and
receive) OSC though proxies, so there could be a considerable overhead.
Despite its ambition to run on any type of network, OSC is being used
mostly with UDP on reliable local networks, with some risks of loosing
packets (so error correction is left as an exercise, or simply ignored).
And it's not clear if the 1.1 spec is even used...
Marc
Le 2021-04-28 à 11 h 16, Fons Adriaensen a écrit :
> The advantage of SLIP over the lenght prefix would be that it allows
> a connection to resync to a packet boundary in case some bytes would
> be lost. But if the transport is not reliable, OSC encoding doesn't
> provide anything to mitigate that. No checksum or forward error control.
> So things would fail anyway, potentially in catastrophic ways.
>
> Another thing missing is even the most basic security, something that
> can't be ignored in these days. Now if that is added, the same layer
> would very probably define packet boundaries anyway. So SLIP doesn't
> add anyting useful.
>
>> for TCP could be added, but the overhead of SLIP seems to add only 4 bytes
>> (32 bits): https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol
> Plus any data bytes that need to be escaped.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu Apr 29 04:15:01 2021
This archive was generated by hypermail 2.1.8 : Thu Apr 29 2021 - 04:15:01 EEST