jinroh/kadoh — comment on commit 4f058a051caa57a0b4f389227e04679116205c72
File: dht/lib/kbucket.js line 124
By alexstrat:

Attend j'ai un gros doute là ! Soit je bugge totalement, soit c'est toi.. Splitter un KBucket, c'est partager l'espace de hash en deux selon la valeur du milieu, non ?

Donc partant d'un KBucket representant 10 bits (pour faire simple) on a `min=0`et `max=10` en puissance, mais qui veut dire en terme de valeur de distance de hash : `h_min = 2^0 = 1` et `h_max = 2^10 -1 = 1023`.

La valeur du milieu c'est grosso modo `512`, donc les hash qui sont plus grands que 512 reste dans l'ancien KBucket dont la valeur minimum passe donc à `h_min = 512` c'est à dire en terme de puissance `min = 2^9`, alors que les hash plus petits strict que 512 passe dans le nouveau KBucket dont la valeur max est `h_max = 511` v'est à dire en terme de puissance `max = 9`.

Donc si dans ton code `_min`et `_max` represent bien des puissances, j'écrirais plutot :

```js
var split_value = this._max - 1;
var new_kbucket = new KadOH.KBucket(this._min, split_value, this._parent_id);
this.setRangeMin(split_value);
```

Et, du coup, j'initialiserais aussi `_min` à 0 plutôt qu'à 1.

Du coup on se retrouverait dans le pire des cas avec 160 KBuckets et chaque KBucket `i` aurait des peers éloignés d'une distance `2^i`à `2^(i+1)`, ce qui correspond à ce qui est écrit dans le papier originel paragraphe 2.2. _Si j'avais une version du papier avec texte selectionable, je t'aurais fait une citation.._

**De plus**, je pense qu'il faut revoir les conditions de splittabilité et de "trop-plein" d'un KBucket :

- **splittable** : le dernier KBucket (`min = 0`et `max = 1`) qui ne contient d'ailleurs qu'un seul Peer (éloigné d'une distance de 1) n'est pas splittable.

- **Trop-plein** : les derniers KBuckets sont pleins bien avant que K ne soit atteint. Outre K, leur capacité maximale est `2^max - 2^min`.

T'en penses quoi ?