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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
