<div dir="ltr">reading through the Aura paper ...<div><br></div><div>TCP and UDP packets both go over IP. At the IP level, they're handled the same. The packet transit time of each is the same. They can both be fast! They just have different properties.<div><br></div><div>the paper isn't particularly forthcoming with regards to Linux networking arcanery. There are many places where UDP packets may be lost, and the paper doesn't indicate the source of packet loss. On the sending side, each outgoing UDP socket has a send buffer that buffers packets to be sent. If that outgoing buffer gets full because your application is writing packets into the buffer faster than your networking card can publish them on the network, the packet will be dropped by the client, and it won't ever get broadcast on the network. On the receiving side, each open UDP socket has a receive buffer for packets that have been received by the network card but have not been read out of the buffer by the application. If that buffer gets full (because you're receiving packets faster than your application can process them), the network card will drop the packets and you'll have packet loss on the receiver.</div><div><br></div><div>The default UDP socket buffer sizes on Linux are pretty small. For running a system with a high volume of UDP traffic, adjusting the kernel options with respect to UDP buffer sizes goes a long way towards mitigating packet loss. On my machine at least, the default UDP socket buffer read size is ~200kb; for a production system, I make that more like 25mb.</div><div><br></div><div>The third major type of packet loss is packets lost in transmission. Although the paper doesn't indicate what fraction of dropped packets were dropped in transit, I suspect that most of the dropped packets were <i>not </i>dropped in transit. My suspicion is based on the fact that I'm fairly certain that if there was significant in-transit packet loss, there would have also been significant in-transit packet loss in the TCP trials, and they would have observed poor TCP performance due to packet re-transmission delays.</div><div><br></div><div>Given the nod to disabling Nagle's algorithm by setting TCP_NODELAY, my guess is they didn't change the UDP buffer sizes, that much of the UDP packet loss was due to UDP buffers being filled, and that there was probably a lot of room for performance improvements to be had in the UDP stack. Of course, they may have tried all this and it didn't make the paper! That is to say, I would be cautious in assuming their conclusion with regards to network protocols has been as fully explored as it could.</div><div><br></div><div><div>(fwiw, and this is rich, I forgot to set TCP_NODELAY on my own thing so it's subject to Nagle's algorithm! But I can't work on it right now; setting TCP_NODELAY on the client's TCP socket will yield latency improvements)</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 1:13 PM mario buoninfante <<a href="mailto:mario.buoninfante@gmail.com">mario.buoninfante@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hi Jordan,</p>
<p><br>
</p>
<p>Thanks a lot for that, I'll give it a try as soon as possible ;)</p>
<p><br>
</p>
<p>Cheers,</p>
<p>Mario<br>
</p>
<p><br>
</p>
<div class="m_-8431616650453311415moz-cite-prefix">On 04/12/2018 17:07, Jordan Orelli
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">ok, I had a little time to look at this, so I
wrote you a simple proxy server in Go: <a href="https://github.com/jordanorelli/tuntun" target="_blank">https://github.com/jordanorelli/tuntun</a></div>
<div dir="ltr"><br>
</div>
<div>there's a binary release here if you want to just have
a downloadable binary to check it out:<a href="https://github.com/jordanorelli/tuntun/releases" target="_blank">https://github.com/jordanorelli/tuntun/releases</a></div>
<div><br>
</div>
<div>and there's an example of how you'd use it from Chuck
here: <a href="https://github.com/jordanorelli/tuntun/blob/master/ex/ex.ck" target="_blank">https://github.com/jordanorelli/tuntun/blob/master/ex/ex.ck</a></div>
<div><br>
</div>
<div>this is a pretty straightforward proxying server to
write. If you're not familiar with writing network
servers, this is a good entry-level project for learning
about it.</div>
<div><br>
</div>
<div>Chuck's subprocess facilities are, ... well, pretty
weird. It doesn't seem like you get the pid of the spawned
process; there's no way to signal it, so there's no way to
kill it from Chuck. This example leaves you with a zombie
process.</div>
<div><br>
</div>
<div>I'm very confused as to how it operates internally,
because it blocks the entire Chuck VM ... <i>unless </i>you
stick an ampersand at the end of your command, which seems
to put the job in the background. It ... it kinda looks
like it's calling exec to exec a bash shell in the <i>current
</i>process? I'm ... a bit baffled by the behavior, to be
honest, but I found a way to work it out.<br>
</div>
<div><br>
</div>
<div>Running it this way means that Chuck launches the
proxying server for you and can tell the proxying server
the ports to use. You could also run the server yourself
outside of Chuck to not have to deal with the weirdness of
Chuck's subprocessing facilities.</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Dec 4, 2018 at 10:59 AM Mark Cerqueira
<<a href="mailto:mark.cerqueira@gmail.com" target="_blank">mark.cerqueira@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Roger Dannenberg did some real-time music
work and compared UDP and TCP. His findings may surprise
you! See 4.2 UDP vs. TCP here: <a href="https://www.cs.cmu.edu/~rbd/papers/icmc01aura.pdf" target="_blank">https://www.cs.cmu.edu/~rbd/papers/icmc01aura.pdf</a>
tl;dr - he ended up going with TCP with some tweaks to
make it more timely.</div>
<div dir="ltr"><br>
</div>
<div>Cheers!</div>
<div><br>
</div>
<div>mc</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sun, Dec 2, 2018 at 12:47 PM Jordan Orelli
<<a href="mailto:jordanorelli@gmail.com" target="_blank">jordanorelli@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>I'm like ... 80% sure that there's no TCP-handling
facilities built in, but I may be wrong here. If there
is, I surely don't know about it.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Can you tell us a little more about your
use case?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">The design goals of TCP and ChucK are
very different with respect to <i>time</i>. ChucK is
designed around guarantees about time and timeliness.
TCP is not designed around timeliness or latency in
general: TCP is designed around guarantees about
ordering (messages always appear in order) and
delivery (messages are guaranteed to be delivered).
Since every byte sent over a TCP socket has to be
eventually acknowledged, and all bytes have to be
processed in order, a stall in the network (a normal
occurrence) could mean later messages being delayed,
much like a traffic jam. It's not possible to have
timing <i>guarantees </i>with TCP.<br>
<div><br>
</div>
<div>I'm not sure how to find it in the source code,
but maybe someone else here knows: does calling
Std.system create a new shell process for each
invocation? That would be a fairly inefficient way
to go about things. Also since you're piping to
another process, that's a new netcat process for
each invocation (so it's either one or two processes
per invocation), and a new TCP socket for every
invocation. TCP is <i>especially slow </i>at <i>the
very beginning of communication.</i></div>
<div><br>
</div>
<div>If I were in your shoes, I would probably write a
separate program that acts as a server and serves an
OSC-based protocol. This server would take your
messages as OSC and translate them and then forward
them to the intended recipient over just one TCP
connection and continue to use that one connection
the whole time. It may or may not respond to your
ChucK program over OSC, depending on whether you
want the ChucK program to get responses to its
requests (probably not?).</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sat, Dec 1, 2018 at 1:25 PM mario
buoninfante <<a href="mailto:mario.buoninfante@gmail.com" target="_blank">mario.buoninfante@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p><br>
</p>
<p>It seems like accessing the shell and use
"netcat" (on Unix) is a possible solution. Quite
an <i>exotic</i> workaround but better than
nothing I'd say.</p>
<p>Something like that seems to work:</p>
<p><i>// run ChucK with "--caution-to-the-wind"</i><i><br>
</i><i><br>
</i><i>"echo -ne '" => string prefix;</i><i><br>
</i><i>"' | netcat 127.0.0.1 3333 " => string
suffix; // netcat <target ip> <target
port></i><i><br>
</i><i><br>
</i><i>while(true)</i><i><br>
</i><i>{</i><i><br>
</i><i> Math.random2(0,127) => int r;</i><i><br>
</i><i> prefix + Std.itoa(r) + suffix =>
string msg;</i><i><br>
</i><i> Std.system(msg);</i><i><br>
</i><i><br>
</i><i> second => now;</i><i><br>
</i><i>}</i></p>
<p><br>
</p>
<p>Please, let me know if anyone has a better
solution.<br>
</p>
<p><br>
</p>
<p>Cheers,</p>
<p>Mario<br>
</p>
<div class="m_-8431616650453311415m_-1842455255522013405m_587405356053983566m_-3928248464589800815moz-cite-prefix">On
01/12/2018 18:04, mario buoninfante wrote:<br>
</div>
<blockquote type="cite">Hi, <br>
<br>
<br>
I also tried opening a file in /dev/tcp/<target
ip>/<target port>, but it didn't work.
I'm on Ubuntu 16.04. Any idea? <br>
<br>
<br>
Cheers, <br>
<br>
Mario <br>
<br>
<br>
On 30/11/2018 16:52, Mario Buoninfante wrote: <br>
<blockquote type="cite">Hi, <br>
<br>
Does anyone know if it's possible to use TCP
instead of UDP in ChucK? <br>
<br>
Cheers, <br>
Mario <br>
</blockquote>
<br>
</blockquote>
<pre class="m_-8431616650453311415m_-1842455255522013405m_587405356053983566m_-3928248464589800815moz-signature" cols="72">--
Electronic Musician, Creative Coder, QA Engineer
<a class="m_-8431616650453311415m_-1842455255522013405m_587405356053983566m_-3928248464589800815moz-txt-link-freetext" href="https://vimeo.com/creativecodingsalerno" target="_blank">https://vimeo.com/creativecodingsalerno</a>
<a class="m_-8431616650453311415m_-1842455255522013405m_587405356053983566m_-3928248464589800815moz-txt-link-freetext" href="http://mbuoninfante.tumblr.com/" target="_blank">http://mbuoninfante.tumblr.com/</a>
<a class="m_-8431616650453311415m_-1842455255522013405m_587405356053983566m_-3928248464589800815moz-txt-link-freetext" href="https://github.com/mariobuoninfante" target="_blank">https://github.com/mariobuoninfante</a>
<a class="m_-8431616650453311415m_-1842455255522013405m_587405356053983566m_-3928248464589800815moz-txt-link-freetext" href="https://bitbucket.org/mariobuoninfante/" target="_blank">https://bitbucket.org/mariobuoninfante/</a></pre>
</div>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" rel="noreferrer" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</blockquote>
</div>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" rel="noreferrer" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</blockquote>
</div>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" rel="noreferrer" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</blockquote>
</div>
<br>
<fieldset class="m_-8431616650453311415mimeAttachmentHeader"></fieldset>
<pre class="m_-8431616650453311415moz-quote-pre">_______________________________________________
chuck-users mailing list
<a class="m_-8431616650453311415moz-txt-link-abbreviated" href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a>
<a class="m_-8431616650453311415moz-txt-link-freetext" href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a>
</pre>
</blockquote>
<pre class="m_-8431616650453311415moz-signature" cols="72">--
Electronic Musician, Creative Coder, QA Engineer
<a class="m_-8431616650453311415moz-txt-link-freetext" href="https://vimeo.com/creativecodingsalerno" target="_blank">https://vimeo.com/creativecodingsalerno</a>
<a class="m_-8431616650453311415moz-txt-link-freetext" href="http://mbuoninfante.tumblr.com/" target="_blank">http://mbuoninfante.tumblr.com/</a>
<a class="m_-8431616650453311415moz-txt-link-freetext" href="https://github.com/mariobuoninfante" target="_blank">https://github.com/mariobuoninfante</a>
<a class="m_-8431616650453311415moz-txt-link-freetext" href="https://bitbucket.org/mariobuoninfante/" target="_blank">https://bitbucket.org/mariobuoninfante/</a></pre>
</div>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" rel="noreferrer" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</blockquote></div>