On the otherhand, maybe we want to just eliminate QR and use something
like this. Nodes have 100ms to reply with a Query Accepted otherwise the
query is deemed to have been rejected. NG should be more that able to
Ed, this is a feasible solution in certain environments. However, the optimal timeout window for every pair of nodes is going to vary widely. The round-trip (out and back) network + OS delivery time is likely to exceed 100ms for many routes. Trying to pick a one-size-fits-all value would _not_ be helpful for this project. QAs that are received too late are _at_least_ as wasteful as a QR (look at what happens in the meantime!). The nodes would need to measure the average round-trip time between them beforehand. This is very complicated to get right, and somehow I expect it would be counterproductive to attempt to implement it in this project, at this time. I posted another devl message earlier that discusses time handling in this kind of distributed environment ("a pointer on distributed programming"). I can't decide if a simple 'backoff for X seconds' message would be a decent gain over current situation or not. You have to account for the send time, receive time, time to act on the message, events that happen asynchronously during this time window ...
however, if X were at least 10 seconds, and things didn't get better for 3 minutes, at least we would be exchanging (far) fewer requests and rejections - each request would get another 'QR/backoff for X' msg. This is an incremental improvement, but suboptimal. Make X too big, and you decrease the granularity of the nodes' coordination/control (and waste available bandwidth). Make X too small, and you don't get much gain over constant "Q,QR,Q,QR,Q,QR..." Plus there is the small time window between when both nodes arrive at the same agreed upon state. I am in favor of dropping requests, but only after it is understood by both ends WHY that is happening. And you still need a periodic update message that says "go again" or "keep sleeping."
Ken
(hope this is helpful)
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
