On Fri, 21 Jan 2011 14:08:35 -0500, Dennis Nezic wrote: > On Fri, 21 Jan 2011 14:05:09 -0500, Dennis Nezic wrote: > > On Sat, 22 Jan 2011 07:59:32 +1300, Phillip Hutchings wrote: > > > > > > On 22/01/2011, at 7:55 AM, Dennis Nezic wrote: > > > > > > > On Fri, 21 Jan 2011 11:51:35 -0700, Ray Jones wrote: > > > >> > > > >> If I understand correctly.... > > > >> > > > >> UDP has no such thing as flow control. So even though your > > > >> machine reads only X packets per second, the sending machine is > > > >> still sending and you're still receiving. If the packets build > > > >> up too far your machine will drop them, but you've already used > > > >> the bandwidth to get them there before they were dropped! > > > > > > > > I agree it's a terrible waste -- but, I say, tough luck. Surely > > > > the senders will throttle back when they start seeing some of > > > > their packets not being acknowledged. (Like I said, we should > > > > avoid this situation as much as possible, but ultimately the > > > > user has to be in control. The network, selfish as this might > > > > sound, comes second!) > > > > > > NO! We're using UDP - UDP packets have no acknowledgment. TCP > > > would behave like you describe, but UDP senders have no way of > > > knowing that there's a problem. > > > > > > Freenet itself acknowledges packets, > > > > That's what I was referring to. > > > > > and that's part of the rate limiting, which obviously has some > > > bugs. Not reading the packets will work for a while, but when > > > packets are read and ack'd the senders will burst again, not > > > knowing there's a limit. > > > > Sure they will know there is a limit -- they will know how long it > > took for the packets to get acked, and how many were dropped. It's > > not perfect, but I'm sure they will know enough to pull back when > > necessary. > > > > > The only solution is to fix the limiter bugs, which is tough > > > for a project with so few developers. > > > > Fixing that is definitely essential, although either way I think the > > user's limit has to be paramount. (Perhaps there are other ways to > > avoid dropping, like having the UDP packets queued into Freenet's > > memory, but not used more than XKiB/second -- so the long ack-ing > > works for a bit longer, rather than dropping the packets, which is > > worse.) > > Bah. Ok, I see your point. The damage is already done when we are > flooded with traffic. There is no point hurting the user more by > dumping those already-arrived packets :b.
So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) _______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
