Cruise <[EMAIL PROTECTED]> writes: > Just another random thought from a lurker...I have a feeling this has > been mentioned before, but I'll throw it in just in case. > > There seems to be great efforts expended in working out the best of > way of telling if a node is overloaded, how many connections it can > accept a minute, etc. etc. > > Recently it's been mentioned that a lot of bandwidth/time (may) be being > used up on sending large amounts of data to nodes that can't respond. > > Surely, a lot of complexity would be removed if some kind of "ping" > message was introduced? Before you initiate the "full" connection, > simply ping each of the nodes you wish to contact. A negative response > (see below), would result in the usual decrement of HTL, and whatever > other responses are appropriate. > > What the negative response is could be one of a few things. A simple > no-response would save the most of an already overloaded node, and > seriously reduces the effect of a ping DOS. It doesn't give the source > node much feedback about why there was no response, however. > There's a couple ways to do this, each with its own problems, as well as a fundamental problem with the entire idea.
Either you wait until a node timesout in response to the ping or you ping lots of nodes and you go with the first to respond. The first takes *way* too long to do, and the second results in bandwidth waste and will route to faster nodes in preference to those that are more correct to route to in terms of the distance metric. But no matter how you do a ping, if you're waiting for some node to respond to the ping, that's adding more latency to each hop; making the request take longer to propogate through the network. If instead of pinging when a message came in, how about pinging every x minutes? That way you pre-emptively know the state of neighboring nodes, and catch most connection/overloading problems before they slow down routing. Or even better, ping nodes you haven't talked to in a while. There's no need to ping nodes you've been exchanging requests with. > A simple response with an estimated "try-again in X secs" value might > be more helpful, but calculating X could be difficult. But likely > easier than another node trying to discover that value. > Some sort of status code on how good the chances are would be nice, but hard to calculate. and we don't want to give out too much information on a node's status for attackers to use. > Finally, the queried node could respond with the standard responses, > depending on the reasons for the ping rejection. > > > Now I'm sure there are reasons why better minds than I haven't decided > to try this previously, but it seems to me that it would save a lot of > bandwidth and time. > It'd waste both, actually. But there is a good idea hiding deep in there anyway. Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
