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.
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
