On Monday 28 April 2008 18:15, Robert Hailey wrote: > > On Apr 28, 2008, at 8:38 AM, Matthew Toseland wrote: > > > Load management proposal: > > > > When we receive a request, we stick it in a queue. The queue is > > limited in > > length, and limited in queue time (probably 500-1000ms). If a > > request is > > still on the queue at the end of the timeout, or if there are too many > > requests on the queue, we reject it. > > You mention the latency cost as 'slight', but adding one second for > every node which rejects a request will add a lot of latency. Rather > than replacing instant rejection outright, perhaps we can still reject > some requests instantly; such as only allowing so many active/pending > requests per-peer.
One objective is to not have to send such rejects. Like I said the queue would be limited to a certain number of pending requests per peer, but by stage 2 we should hardly ever have to reject such requests because our peers will know how long their queues are and not go over them. This would be a significant saving IMHO: far fewer requests would be pointlessly sent only to be rejected. > > > We have two options afaics: > > 1. We start the remote request closest to our location. We keep the > > separate > > request starter for local requests. > > What a fascinating effect this might have on load balancing. > Effectively preferring 'local' traffic. Although I am not sure of the > need, etc it resonates with the structure of small world networks > (most links are short links --?--> most requests are near requests). > Is the intent to make distant requests make fewer (but larger) 'jumps' > across the network? The idea for the small world network is that most links are short but some links are long. There is a genuine question here of whether this would mess things up by blocking too many "long" requests... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080429/f93afb91/attachment.pgp>
