Le 2021-04-28 à 10 h 22, Fons Adriaensen a écrit :
> Can't find any official reference to this, but one way to send OSC over
> TCP was to prefix each packet with a 32-bit int (in network byte order
> of course) giving the lenght of the packet [1]. IIRC there was even some
> RFC about sending any type of packets over TCP by doing exactly that.
> In 1.1 this was replaced by SLIP encoding, destroying the nice 32-bit
> alignment of all data elements that we had before. Apparently this
> was selected only because the OSC authors happened to have some
> hardware using SLIP encoding -- not a good idea IMHO.
From the 1.1 paper
(https://cnmat.berkeley.edu/publications/features-and-future-open-sound-control-version-11-nime)
:
"This new specification enormously expands the range of protocols and
hardware transports that can be used to communicate OSC encoded packets
including Firewire, Ethernet, and USB (using TCP/IP); RS232 and RS422
and Serial USB and Serial Bluetooth and Serial Zigbee"
So it looks like using SLIP is a compromise. Maybe the method you
mentionned 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
(disclaimer: I'm not a network specialist)
Marc
_______________________________________________
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