<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Le 2021-04-28 à 10 h 22, Fons Adriaensen a écrit : <blockquote type="cite" cite="mid:20210428142242.quf2u25p4i2cynva@mail1.linuxaudio.cyso.net"> <pre class="moz-quote-pre" wrap="">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.</pre> </blockquote> From the 1.1 paper (<a class="moz-txt-link-freetext" href="https://cnmat.berkeley.edu/publications/features-and-future-open-sound-control-version-11-nime">https://cnmat.berkeley.edu/publications/features-and-future-open-sound-control-version-11-nime</a>) : "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): <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol">https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol</a> (disclaimer: I'm not a network specialist) Marc </body> </html>