I read here http://stackoverflow.com/questions/15060180/what-are-the-chances-of-losing-a-udp-packet this:

Packet loss happens for multiple reasons. Primarily it is caused by errors on individual links and network congestion.
Packet loss due to errors on the link is very low, when links are working properly. Less than 0.01% is not unusual.
Packet loss due to congestion obviously depends on how busy the link is. If there is spare capacity along the entire path, this number will be 0%. 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.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.


How do I config my router to do only this job and, in this way, make "spare capacity along the entire path"?




El 17/02/16 a las 20:39, Chris McCormick escribió:
On 18/02/16 07:33, Chris McCormick wrote:
On 18/02/16 05:07, Mario Mey wrote:
A buddy from a group suggested me to send "bursts of packets" instead
only one packet... considering this packet as important.

If you need guaranteed, ordered delivery from one machine to another
then you should use TCP sockets instead of UDP sockets. Since you seem
to be sending directly between two machines this is ideal. In Pd it is
trivial to set up a TCP connection with [netsend] and [netreceive]. TCP
has slightly larger overhead than UDP because of the ACKs but I think
over WiFi you will not notice the difference.

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.

Cheers,

Chris.