<div dir="ltr">I've used OSC pretty heavily with Erlang recently, and:<div><br></div><div>1) use wired connections where possible; wireless connections experience significantly higher packet loss, and at least two different models of wireless router displayed unusual behavior in which a steady train of UDP packets would get increasingly geometrically delayed for no apparent reason. </div><div><br></div><div>2) consult musician forums about wireless router brand / model / firmware combinations that seem to work with the specific tools you want to use, if you are going to use something like an iPad with TouchOSC or Lemur etc. as a manual controller. </div><div><br></div><div>3) use OSC bundles where possible; not all languages have libraries which are good at that particular section of the spec, but properly implemented bundles can significantly improve sync and a feeling of snappiness in non-musical applications, such as higher level control.</div><div><br></div><div>4) Limit your packet sizes to 1500 bytes or lower on a LAN. For single messages this is usually pretty easy unless you're trying to send data instead of commands, which I don't recommend. You can breach the limit if you pack a bunch of commands into a bundle, but if your application layer is smart, it can fill up an outgoing packet to 500 bytes or whatever, and then save off any further messages for the next packet. With good switches, good PHYs (e.g. Intel), good OS with well-tuned buffers or good defaults, you should be able to run at 100Mb line rate. In the real world, sometimes you don't get to pick all of those things, so having your OSC code be tunable (or self-tunable) down in packet size and packet rate is a good practice.</div><div><br></div><div>5) OSC is super awesome because there's a bunch of controllers, libraries, real time graphical monitors, etc., for it, and it's pretty familiar in the entertainment space, but it's also pretty verbose and hefty on the wire. Cap'n Proto, protobufs and thrift are nearby cousins that deserve a look or two if you're really pushing OSC out of its comfort envelope.</div><div><br></div><div>F.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 5:24 PM, Serge Aleynikov <span dir="ltr"><<a href="mailto:serge@aleynikov.org" target="_blank">serge@aleynikov.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In addition to what others have said, the max UDP binary size that can be sent/received is:</div><div class="gmail_default"><font face="arial, helvetica, sans-serif">64k - (sizeof(IPHeader) + sizeof(UDPHeader)) = 65535- (20 + 8) = 65507. This is the UDP protocol's limitation. I would say if you use UDP, the {packet, N} option makes little sense, since each udp message is delivered as a whole (UDP is message oriented vs. TCP that is byte-oriented).</font><br></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">I see between your 3rd and 4th questions there's some confusion. UDP fragmentation may happen at the network layer (IP) when sending a large datagram (> MTU size), but it's defragmented by the network stack, and delivered to the transport layer (UDP) and consequently the user space as a whole message (preserving message boundaries)</font><span style="font-family:arial,helvetica,sans-serif">.</span></div><div class="gmail_default"><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_default"><span style="font-family:arial,helvetica,sans-serif">Regards,</span></div><div class="gmail_default"><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_default"><span style="font-family:arial,helvetica,sans-serif">Serge</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 10:27 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I have a simple UDP client/server<br>
<br>
The server is on a fixed port 4567 - I open it like this<br>
<br>
{ok, Socket} = gen_udp:open(4567, [binary]),<br>
<br>
then wait for registrations<br>
receive<br>
{udp, Socket, _Ip, _Port, <<"register">>) -><br>
<br>
<br>
Clients do this:<br>
<br>
{ok, Socket} = gen_udp:open(0, [binary]),<br>
gen_udp:send(Socket, "localhost", 44567, <<"register">>),<br>
...<br>
<br>
I'm testing on "localhost"<br>
<br>
After registration the processes send binaries to each other<br>
<br>
This works fine for small binaries but gen_udp:send fails with<br>
{error,emsgsize} for large binaries<br>
<br>
So I have a few questions:<br>
<br>
1) Can I find out the max binary size that can be sent/received?<br>
2) Can I increase the max size?<br>
3) Is there a guaranteed minimum packet length that will not be fragemented?<br>
3) Can received packets be fragmented - TCP has a {packet,N}<br>
option and some built-in defragmentation, what's the story for<br>
UDP?<br>
<br>
I think I know the answers to these but I'm not really sure - could somebody<br>
who really knows enlighten me?<br>
<br>
Thanks<br>
<br>
/Joe<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>