Subject: Re: [P2PSIP] reload issues update

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Oct 2009 19:04:19 -0600

I see your point. This should be fixed in next rev.

On Aug 19, 2009, at 12:09 AM, jc wrote:

> Cullen, csv is fine, thx.
>
> While I am here:
>
> Section 9 states "at least three" predecessor's and successor's  
> while section 9.1 states "3".  IMHO, section 9.1. needs a bit of  
> rewording because you may or may not have three peers clockwise or  
> counterclockwise at any given time.
>
> So technically in section 9.1 the neighbor table SHOULD contain at  
> least 3 peers before this peer and at least 3 peers after it in the  
> DHT ring.
>
> Are we clearly stating that the neighbor table is indeed at most 6  
> node id's with 3 in each direction around the ring? Are we stating  
> that you should not add to the back or front list if they contain  
> already three entries?
>
> 9.  Chord Algorithm
> The original Chord algorithm specified a single predecessor and a
>      successor list be stored. chord-reload specifies at least three  
> of
>      each.
> 9.1.  Overview
> The neighbor table contains the 3
>   peers before this peer and the 3 peers after it in the DHT ring.
> Julian Cain
>
> On Aug 18, 2009, at 8:37 AM, Cullen Jennings wrote:
>
>>
>> I'm still collecting up issues on the reload and sip usage draft  
>> but the initial list is in a spreadsheet at
>>
>> http://svn.resiprocate.org/rep/ietf-drafts/p2psip/issues.csv
>>
>> I realize there are better tools for tracking bugs than a  
>> spreadsheet in a source code control system but this is something  
>> everyone can use, works across a wide range of operating systems,  
>> and allowed multiple people to work offline and make changes.
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>