On Jan 10, 2008, at 5:10 PM, Matthew Toseland wrote: > With such an aggressive SEND_TIMEOUT, this borders on reviving > NGRouting - > it's a major change to routing, which since it hasn't been simulated > will > almost certainly cause major problems. No?
I'm thinking that the SEND_TIMEOUT will need to be increased, I really am not familiar with what the average network condition will be like. Feel free to change the SEND_TIMEOUTs to your liking. Also, I noticed that the htl is still decremented if we skip a peer w/ conditionalSend (or on disconnect). On Jan 10, 2008, at 5:20 PM, Matthew Toseland wrote: > Just because our queue of data to send to a node is full doesn't > mean its > queue of data to send to us is full. Queue based load management > would have > to take the latter into account. In fact, it would have to take not > only the > data currently queued but also the data that is likely to become > queued into > account. The liability limiting code works on this principle. Various > proposals for load management work similarly by passing back > information on > how many requests can be made in the near future - but these will > not be > deployed until they have been simulated. > > So please show me that this has no effect on routing, or revert it. My initial impression was that with SEND_TIMEOUT being either ACCEPTED_TIMEOUT (equivalent to sendAsync) or one minute (equivalent to sendSync) that it would be the same. It does change the behavior though (as the packet is withdrawn from the send queue, or not sent). Until it can be simulated, I can simply flip the send back to sendSync(). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080110/8df4c446/attachment.html>
