On Thursday 10 January 2008 23:35, Robert Hailey wrote: > > 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.
IMHO it should be equal to ACCEPTED_TIMEOUT. Although with message prioritisation I'm not sure conditionalSend does anything useful? > > 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 -------------- 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/20080111/6f210b41/attachment.pgp>
