<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" alink="#EE0000" link="#0B6CDA" text="#000000"
vlink="#551A8B">
<div class="moz-cite-prefix">I read here<i> </i><a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/15060180/what-are-the-chances-of-losing-a-udp-packet">http://stackoverflow.com/questions/15060180/what-are-the-chances-of-losing-a-udp-packet</a>
this:<br>
<i><br>
</i>
<p><font color="#990000"><i>Packet loss happens for multiple
reasons. Primarily it is caused by errors on individual
links and network congestion.</i><i><br>
Packet loss due to errors on the link is very low, when
links are working properly. Less than 0.01% is not unusual.</i><i><br>
Packet loss due to congestion obviously depends on how busy
the link is. <b>If there is spare capacity along the entire
path, this number will be 0%.</b> But as the network gets
busy, this number will increase. When flow control is done
properly, this number will not get very high. A couple of
lost packets is usually enough that somebody will reduce
their transmission speed enough to stop packets getting lost
due to congestion.</i>The text in bold caught my attention,
because I use my router (I have a TP-LINK TL-MR3020 and a
TP-LINK TL-WR841ND) only for this. Not internet, not other
computer/device connected to it.</font><br>
</p>
<br>
How do I config my router to do only this job and, in this way,
make "spare capacity along the entire path"?<br>
<br>
<br>
<br>
<br>
El 17/02/16 a las 20:39, Chris McCormick escribió:<br>
</div>
<blockquote cite="mid:56C504A1.9080106@mccormick.cx" type="cite">On
18/02/16 07:33, Chris McCormick wrote:
<br>
<blockquote type="cite">On 18/02/16 05:07, Mario Mey wrote:
<br>
<blockquote type="cite">A buddy from a group suggested me to
send "bursts of packets" instead
<br>
only one packet... considering this packet as important.
<br>
</blockquote>
<br>
If you need guaranteed, ordered delivery from one machine to
another
<br>
then you should use TCP sockets instead of UDP sockets. Since
you seem
<br>
to be sending directly between two machines this is ideal. In Pd
it is
<br>
trivial to set up a TCP connection with [netsend] and
[netreceive]. TCP
<br>
has slightly larger overhead than UDP because of the ACKs but I
think
<br>
over WiFi you will not notice the difference.
<br>
</blockquote>
<br>
One issue with using a TCP socket is negotiating the initial
connection. Pd requires you to enter the exact IP address which is
a bit cumbersome, especially during set up for live performance
with Pd. UDP packets on the other hand allow you to send in
"broadcast" mode. If [netreceive] allowed you to obtain the source
IP address of incoming broadcast packets then it would be possible
to use that to negotiate a TCP connection back to the source
address after doing a "discovery" broadcast & reply exchate -
kind of like zeroconf/bonjour. I'll have a think about a patch to
submit to Miller for accomplishing this - should be small and
simple.
<br>
<br>
Cheers,
<br>
<br>
Chris.
<br>
<br>
</blockquote>
<br>
</body>
</html>