On Fri, Jun 02, 2006 at 09:05:52AM -0400, Colin Davis wrote: > > On Jun 2, 2006, at 8:18 AM, Matthew Toseland wrote: > > >On Fri, Jun 02, 2006 at 08:13:55AM -0400, Colin Davis wrote: > >> > >>I think the first thing to do is to add a warning, when the node is > >>spending more than XXX% of it's bandwidth/time checking node status. > > > >Possibly. > > Great. This is fairly trivial, but lets people know that they are > being stupid.
I'm not promising anything. But you can file a bug for it. :) > > >>The second is to change the delay between checks to see if a node is > >>back up. > > > >No. Some NATs have tunnel timeouts of under 30 seconds. We cannot > >therefore increase the delay over that amount. That is the unfortunate > >reality; everyone is NATted, and it's a PITA, but that's life. > > Forgive my ignorance, but it sounds like we're confusing two distinct > issues. > > The first issue is maintaining a connection to a node- For this, I > understand that a heartbeat needs to be sent out every ~30 secs, to > keep the connection running through the NAT punchthrough... > > But the second is determining if the node is up at all. I don't see > any reason this has to be the same heartbeat, with the same frequency. > If I ask every one of my disconnected nodes if it is up (and tell it > that I am up) only once / hr, but do it immediately on startup, that > doesn't affect the above heartbeat... No. The problem is not us determining whether the node is alive. It is to keep the UDP hole punching tunnel open. If the router has a timeout of 30 seconds, then we must send one packet to the node every 30 seconds, period. At both sides. Otherwise, any occasional packets we do send _will not arrive_ because the tunnel will have been forgotten and therefore the packets will be dropped! Both sides must be sending at a frequency of at least once every 30 seconds, in order for a connection to succeed. Now, we could only do this every hour - but this would require precise time synchronization on both ends, or a very long window during which to send the handshakes. This isn't worth it IMHO. All we can do is warn the user "You have 300 disconnected nodes. You are using 30kB/sec just to try to connect to them. Please note that in order to connect to a node, both sides must have added the other's reference. We suggest that you remove some nodes!" > > Example- Nodes A, B, C and D. > > > Nodes A and B are running 24/7 > They exchange heartbeats every 30 secs, and punch through NATs. > > > > Nodes C and D are transient- They run when the user has free > bandwidth, etc. > There is no reason that A and B should be trying to connect to these > machines every 30 secs.... There is every reason. Unless A and B are not NATted, or have successfully forwarded their ports. In which case, they could perhaps have connection backoff, and then send frequently when contacted by C and D. I'm not sure whether there would be any point in special casing this though; only experts and a few LAN-less idiots will be port forwarded / directly connected. It's probably better to just warn the user when your attempts to connect to other nodes are using most of your bandwidth. > > > > If C and D send a connection to all the nodes on their list on > startup, telling them that they are up, and trying to establish the > connection, then they are OK. > The reply gets back, since it is within 30 secs, it goes through the > passthrough. It can't go back because A and B are not sending to C and D. Therefore A and B, being NATted, will not receive the packet from C and D - except possibly once an hour, resulting in C and D having to wait an average of half an hour to connect! For UDP hole punching to work, both sides must be simultaneously sending. > > A and B can gradually increase the rate at which they check for C and > D. If they don't get a reply after 30 secs, they increase it to a > minute. If they don't get a reply after a minute, they increase it to > 10 minutes, etc. > Eventually, they hit a max in freenet.ini, and don't check any less > frequently than that. (Ie, always check at least once an hour) > > But if node C or D come back online, they are sending a connection > request to A and B /anyway/! So what? A and B are not sending a connection request to C and D, so A and B *will not receive the incoming packet*. > The fact that we aren't checking for another hour doesn't hurt them. > > What am I missing? See above. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060602/a3393c15/attachment.pgp>
