On Monday 10 November 2003 01:02 am, Ken Corson wrote: > Jon: > on a more serious note, how do you know the upstream node is in any > better condition to handle the request ? this seems like avoiding > our local responsibility... i suppose it is fair to say, if a node > doesn't reject a request, that means it is willing to handle it. > We could try to shift our responsibility. But the local node made the > same commitment, first. In the time elapsed between accepting a request, > and receiving the response, our overall load may have swung against us. > We should attempt to control "load" at the link level (between peers) > as well, perhaps by limiting simultaneous trailers between a pair of > nodes. Apologies if this is already done and I just don't know it yet. > The appropriate limit per link will be different for every pair of > nodes, based on their bandwidth capacities, and their numbers of peers.
Since you have to send out a message anyway, IE back to the node that made the request, it would be just as fast to send the request to the upstream node and tell it to send the data back to the first node. That way nobody has to establish a connection unless they get the data. However you still have to establish a connection, (very costly) and making this happen more under load, will not improve things. So it would be best if this were done only if the upstream node already had a connection to the downstream one. However that is so rarely true it would hardly be of any use. So to make it more usefull, this could be made the default behavior if the upstream node happens to notice that it has a connection the node listed as the requester. Then, so the intermediate node, knows the data actually was transfered and does not spend time sitting around waiting for it, the requesting node tells it if it gets the data. This would all work just fine. But it becomes a minor routing improvement and not a solution to load problems. _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
