Le problème viens probablement du fait qu’un noeud a du mal a se faire connaitre en W2P v1, je prévois de corriger ce problème en WS2P v3 avec un signal spécifique permettant a un noeud de se faire connaitre, mais se sera seulement pour la 1.7.
je n’aurais hélas pas le temps d’investiguer d’ici les rml10 la j’ai la te dans le gidon 
Il y a peut-être un peu de cela mais je constate un vrai bug plus profond, il y a un réel blocage reproductible. Je suis dessus.
edit : ah mais non en fait tu as carrément raison ! avec BMA d’activée la fiche de pair est propagée, ce qui déclenche les connexions INCOMING vers les nœud. Par contre pour ce qui est des échecs des connexions OUTCOMING, ce sont peut-être les pools de connexions qui sont pleins alors ?
Oui beaucoup sont plein, typiquement mes nœuds publics sont constamment plein en INCOMING, mais il n’y a pas que ça. J’ai déjà eu des cas de timeout alors que le noeud contacté avait de la place, peut être trop occupé a calculer ou a faire autre chose. Le thread qui est censé listen ne réagi pas a temps tout simplement (en tout cas c’est ce que j’ai observer au débugguer sur ce problème que j’ai déjà rencontrer)
Oui ça ne m’étonne pas, en cas de pépin dans la connexion j’ai fait en sorte que le nœud contacté ne réponde pas plutôt que d’envoyer un refus. C’est pour éviter les attaques DoS notamment.
Donc en attendant qu’on trouve de meilleures solutions :
je suggère qu’on augmente le nombre max de connexions INCOMING par défaut pour la 1.6.15, il semble bien que 10 c’est insuffisant. On peut passer a 15 ou 20 
Je me pose la question de ce réglage car c’est un moyen “d’interdire” à des nœuds de se connecter si la valeur mise par tous les noeuds est trop basse?
15/20 aujourd’hui est peut-être suffisant mais dans l’avenir nous allons rencontrer le même problème, non?
15/20 en configuration par défaut alors, mais ne modifions pas une configuration existante, car l’utilisateur peut avoir volontairement choisi la valeur 10 par exemple.
Tout à fait c’est déjà ce que je suggérai 
Non c’est comme la toile de confiance, plus elle est grande et plus c’est facile de trouver des certificateurs 
De la même façon plus il y aura de nœuds ws2p public et plus il sera facile d’en trouver des dispo, aujourd’hui il y a en fait très très peu de nœuds ws2p publics fonctionnels !
Je lis trop vite, désolé.
D’ailleurs tu suggérais un intervalle ? Si oui alors je suggérerais aussi une autre chose : que le nombre de connexions sortantes (OUTCOMING) soit inférieur (par défaut) au nombre de connexions entrantes (INCOMING), afin de contrebalancer le fait que tout nœud n’offre pas de WS2P public.
Ah donc y en a quand même, c’est rassurant.^^
Mais du coup je serais curieux de voir les configs pour que ça tourne bien en ws2p…
Exactement l’idéal me semble être un ratio 1/4 :
outcoming par défaut : 5
incoming par défaut : 20
Attention je parle uniquement des nœuds publics, il y a plein de nœuds privés tout à fait fonctionnel, en fait tous les nœuds 1.6 qui sont synchronisés soit environ une trentaine !
Oui oui j’avais bien compris.
done
5 connexions sortantes suffisent largement pour rester synchro, la preuve avec mon noeud full tor sans bma qui est déjà sur maxPrivate = 5 depuis plusieurs semaines :
Quel débit internet entrant/sortant as-tu ?
C’est un noeud full tor donc le débit change a chaque fois que le chemin tor change, et il est parfois très très failble, je suis donc convaincu que les faibles débits ne posent aucun problème pour ws2p, la cause est ailleurs !
Ah oui, j’avais lu trop vite.
Donc les décrochages viennent d’ailleurs, le paramètre “bmacrawler” changerait de lui-même pour une raison obscure ?
Par ailleurs je constate sur mon interface graphique un port dédié ws2p et identifié sur ma clé membre selon une ip qui n’est pas la mienne et un port que je n’ai pas configuré. Ça représente une connexion ws2p entrante ?
