[PD] Burst of packets.
mariomey at gmail.com
Thu Feb 18 19:42:47 CET 2016
/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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list