-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ken Corson wrote:
| Martin Stone Davis wrote: | |> Martin Stone Davis wrote: |> |>> We start at the top of the list, and see who is going to make our |>> will the fastest. Since our lawyer is "backed off" at the moment, we |>> go with our chef. | | | important: "at the moment" . How big do we consider this "moment" to | be ? 100ms , 5 seconds, a singular point in time ? hmmm.... | |>> The solution is to look ahead in our list until we find a nice |>> query/node combination. This could be done by sampling a certain |>> number of queries from the ticker randomly. Then, for each one |>> sampled, and for each node in the RT, calculate estimate(). Pick the |>> *combination* with the smallest value. | | | This is a form of queueing, even though we use a 'bin' instead of | a formal 'queue.' I like it muchly, however, the timeout 'period' | on the requesting end needs to be considered / adjusted. What is | the upper limit of loiter time on the requestee ? This clearly | introduces some latency along the query path, at each hop. Which | probably has the payoff of vastly better query throughput in the | freenet network. But increases wait time for someone sitting at | a browser. Which is more important for this project ? Only Ian | could tell us - it is (originally) his design, after all. It | seems that people (would like to) use this network for file | distribution (other than HTML files) ... The obvious difference | here is that we would be shifting from a "forward instantaneously" | strategy to a more efficient queueing model. Plus we are making | this tradeoff in order to preserve our "route to the best node | with best effort" concept, rather than trading off best routing | for best speed. | | |>> This has nothing to do with load balancing, but should improve |>> routing, while increasing CPU usage by some unknown amount. Thoughts? | | | Actually this has A LOT to do with load balancing, indirectly. | Given that the requestor should have a timeout capability, how | would the requestee handle timeouts on his end ? Just drop them? | Pass back a QRejected message to the requestor ? Maybe buffer | these rejections and pass back a block of them, every XXX ms ? | The central issue is efficient state chain maintenance at the | requestor.
Isn't that sort of what happened when we stopped QR'ing due to bandwidth? We'd keep queuing requests, until either the other node figured we were taking too long (and lowered out estimate thusly), or routingTime / messageSendTime exceeded the threshold and starting QR'ing.
I don't know how Freenet dequeues the requests, but if it did in a FIFO, ~ you are proposing instead if we have a request and node with good estimate with respect to that request, we move it to the head of the queue? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/uSprhctESbvQ8ZwRAixjAJ46ov97xxfIwAinn8TTtrE5F7dLswCfVoT3 crvp3Kt8C5tcbo1i7jo5oxs= =lCK8 -----END PGP SIGNATURE-----
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
