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 protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
