On Jan 23, 2008, at 6:23 PM, Matthew Toseland wrote:
> Were inserts broken too?

No, some time ago I switched the order of starting the background  
transfer of CHKs versus the reception of messages. When diagnosing the  
CHK problem I found out that this is counter productive. Both versions  
work, the difference is when the block transmitter begins:  
(16727<=version<17216) will start it AFTER it finds the route,  
(16727>version>=17216) will start it as soon as appropriate.

Looking at the diff, I forgot to comment about the receiveFailed/ 
return statement which was removed. It was redundant, as you can see  
the top of the same inside the while loop, but it is also  
pragmatically wrong, as we should not ever send a datainsert without  
starting the transfer (according to the counterpart: InsertHandler);  
even if it immediately fails, then it propagates knowledge of the  
failure rather than a timeout.

--
Robert Hailey

>
> On Wednesday 23 January 2008 19:37, robert at freenetproject.org wrote:
>> Author: robert
>> Date: 2008-01-23 19:37:39 +0000 (Wed, 23 Jan 2008)
>> New Revision: 17216
>>
>> Modified:
>>   trunk/freenet/src/freenet/node/CHKInsertSender.java
>> Log:
>> revert r16727: it only breaks chk pipelining
>>
>>
>> Modified: trunk/freenet/src/freenet/node/CHKInsertSender.java
>> ===================================================================
>> --- trunk/freenet/src/freenet/node/CHKInsertSender.java      2008-01-23  
>> 18:56:33
> UTC (rev 17215)
>> +++ trunk/freenet/src/freenet/node/CHKInsertSender.java      2008-01-23  
>> 19:37:39
> UTC (rev 17216)
>> @@ -425,8 +425,8 @@
>>                      }
>>
>>                      if(logMINOR) Logger.minor(this, "Sending data");
>> -            if(receiveFailed) return;
>> -
>> +                    startBackgroundTransfer(next, prb);
>> +                    
>>             while (true) {
>>
>>                              if (receiveFailed)
>> @@ -477,11 +477,11 @@
>>                                      }
>>                                      // Finished as far as this node is 
>> concerned
>>                                      next.successNotOverload();
>> -                                    //RNF means that the HTL was not 
>> exhausted, but that the data  
>> should
> still be sent.
>> -                                    startBackgroundTransfer(next, prb);
>> +                                    //RNF means that the HTL was not 
>> exhausted, but that the data  
>> will
> still be stored.
>>                                      break;
>>                              }
>>
>> +                            //Can occur after reception of the entire chk 
>> block
>>                              if (msg.getSpec() == DMT.FNPDataInsertRejected) 
>> {
>>                                      next.successNotOverload();
>>                                      short reason = msg
>> @@ -544,7 +544,6 @@
>>                                      // Our task is complete, one node 
>> (quite deep), has accepted the
> insert.
>>                                      next.successNotOverload();
>>                                      // The request will not be routed to 
>> any other nodes, this is  
>> where
> the data *should* be.
>> -                                    startBackgroundTransfer(next, prb);
>>                                      finish(SUCCESS, next);
>>                                      return;
>>                              }
>>
>> _______________________________________________
>> cvs mailing list
>> cvs at freenetproject.org
>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
>>
>>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl


Reply via email to