Quite a large part of the code does similar things. We only hang onto the request once it has reached the transferring stage (hence the state ReceivingReply). I am of the opinion that we need to send all messages such as Accepted and QueryRestarted asynchronously, and use an internal message LostRequester when the send fails, to tell the node not to try hard, since we cannot send it back to the requester. Any comments?
On Tue, Aug 12, 2003 at 11:39:15PM +0100, Toad wrote: > It would make life easier for me if we did not have to wait for the > Accepted to be sent before starting the request in NewDataRequest. I > have local code which does this, and thus makes sending Accepted > non-blocking, and if it fails, simply logs at MINOR (as we do now), but > leaves the request alone. The current behaviour is to send the accepted, > and then if that fails, abort the request; if it succeeds, execute the > request. The new behaviour would reduce request latency, and IMHO is not > really exploitable (any more than the current code... of course you can > send a bazillion requests and not listen to the results, I'm not sure > how much that is changed by this...), and eliminates threads blocked > sending Accepted's without having to introduce a new State for > NewRequestSendingAccepted or something similar (this approach will > eventually have to be taken for DataRequest sending). The code is > trivial, the big question is is it an acceptable change to the network > behaviour? > -- > Matthew J Toseland - [EMAIL PROTECTED] > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
pgp00000.pgp
Description: PGP signature
