>The alternative is for a node to try to maximize the per-transfer=20 >connection speed by rejecting new requests when the upstream connection=20 >speed is maxed out. Some claim that this is a terrible idea and will=20 >screw up routing because it will be impossible to get a node to accept a=20 >datarequest, but I disagree.
The right way to do this is to list the reason the query got rejected, i.e. too many trailing fields already being serviced. But there's even better option: Every server in McDonalds can provide you with any item on the menu, but in McFreenet, only one server may have the requested item. In this case, the exchange would proceed: Client: I want key X. Server: I have key X, but I'm too busy. I may free up in Y time. Client: Ok, I'll wait, put me on your send queue OR Client: Forget it. (or no reply at all) such exchange includes an extra message passing between the client and the server, but with the recent fixes that should take no time at all. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
