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@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
