Installé sur ubuntu et sur un raspi 3 avec strech, les 2 sont synchro…
Tout justement, a quoi ça sert de nous prendre la tête a créer un réseau p2p, une blockchain et pow personnalisée etc, si c’est pour se condamner a ne pouvoir utiliser que l’internet classique ?
Pour avoir un réseau duniter p2p fonctionnel derrière Tor, c’est à dire qui se suffit a lui-même, il faut toucher a la priorisation des connexions, ainsi qu’a la définition des endpoint or cela n’est actuellement pas faisable via un module.
En théorie ce n’est pas impossible mais en pratique ça aurait été infiniment plus difficile de modulariser entièrement les fonctionnalités liés a Tor, cela aurait demander beaucoup de changements dans la structure du cœur pour que beaucoup plus de fonctions clés soit modifiables par des modules, je n’avais ni le temps ni le niveau pour faire ça.
Bref, il faudrait permettre de modulariser les modules réseau existant pour y injecter les fonctions de remplacement, ça me semble être un véritable casse-tête pour pas grand chose, je n’investirai pas mon temps la dedans, je n’y vois pas l’intérêt…
1 Like
Oui c’est surtout cela, aujourd’hui c’est compliqué de faire une surcharge “TOR” dans un module à part. Alors pour le moment, ce que tu as fait me paraît aussi le plus simple.
Par contre rien ne dit qu’il n’existera pas demain un autre protocole que TOR, puis un 3ème, puis un 4ème … et alors un mécanisme plus général de surcharge deviendra intéressant à développer.
3 Likes
C’est certainement un peu lourd, mais on arrive en phase inertielle désormais donc ça me semble tout à fait normal.
Oui, enfin le “bien fonctionnelles” ça n’a pas toujours été vrai 
Toutefois comme je codais à 99% du temps tout seul, c’était le plus efficace pour maximiser ma productivité et faire avancer Duniter.
Mais aujourd’hui nous sommes au moins deux, et là ça change tout ! Nous avons un code commun, ce qui implique un besoin de nouvelles règles pour assurer que chaque développeur ne produise pas d’actions nuisibles pour les autres.
À noter quand même que passer de 1 à 2 développeurs n’apporte pas que de la lourdeur : personnellement je me sens immensément plus léger depuis que Eloïs s’occupe de gérer les releases et apporter ses propres contributions. Cela me libère l’esprit de façon très importante, vous n’imaginez même pas ! J’ai beaucoup plus d’énergie qu’avant et m’attaque enfin à des tâches qui demandent pas mal de concentration.
Passer à plusieurs développeurs change complètement le rapport au code, personnellement je vis cela extrêmement positivement !
10 Likes
Mon nœud avait l’air coincé (en 1.6.11) alors je l’ai mis à jour, et il est toujours coincé (selon Cesium).
Plus précisément il calcule bien le bon bloc (69352 à l’heure où j’écris), il apprend bien quand il y a de nouveaux blocs, mais il est noté en retard sur https://g1.duniter.fr/#/app/network (au block 69218). C’est d’autant plus surprenant que je vois que le dernier bloc que j’ai calculé est le 69336.
C’est grave, docteur ?
@jytou quand tu sera dispo tu pourra livrer la 1.6.14 le commit de version est déjà fait, tu a juste a faire :
git checkout 1.6
./release/new_prerelease.sh 1.6.14
le changelog :
- Correction des bug #1090, #1196, #1200, #1201, et #1202
- Upgrade dépendance ws 1.1.1 to 1.1.5
- Activation automatique de BMA si la commande
wizard networkest utilisée
Le fait que nous appliquions autant de correctif avant d’officialiser cette version 1.6 est bon signe, cela veut dire que nous devenons plus exigeants suite a la montée en charge du réseau (plus de nœuds) et a la montée de l’intertie (plus de temps avant que tout le monde applique une maj officielle)
@Alan_Schmitt les problèmes que tu soulève ici concernent Cesium pas Duniter !
Je vois bien ton head sur mes nœuds et tu est bien affiché comme en 1.6.13 et synchroniser sur le dernier bloc 
EDIT : Il faut comprendre que les clients Cesium et Sakia ne voient le réseau qu’a travers les nœuds ayant activer BMA, les informations sur les nœuds sans BMA leurs arrivent donc en retard voir pas du tout !
Pour Sakia, c’est “pas du tout” ^^
C’est parti. Je vais d’ailleurs essayer en mettant un peu plus de CPU pour les VM, histoire de voir si ça accélère un peu le schmilblick. (sauf si @cgeek vient hurler ici qu’il ne faut surtout pas faire ça… je suis d’humeur joueuse aujourd’hui)
2 Likes
Pour une future version de sakia tu peut te baser sur les heads fournis par les nœuds membre qui ont BMA, par exemple pour mon noeud membre g1-monit : http://g1-monit.elois.org:10901/network/ws2p/heads
EDIT : En plus tu a la signature de chaque clé a qui appartiens le head donc tu peut même te baser sur les nœuds miroir tu est sur qu’il ne peuvent pas mentir sur le contenu du head sinon la signature serait invalide 
Oui mais ils peuvent mentir par omission (nœuds membres comme non-membres d’ailleurs), et montrer de vieux HEADs faisant croire à une désynchronisation. Ils ne peuvent certes pas faire croire à un fork par contre.
1 Like
Voila qui est fait pour linux/windows, la release arm est dans le four…
2 Likes
Il suffit de demander tout leur heads a X nœuds (une dizaine par exemple) et en garder pour chaque UUID que le head le plus haut, qui est en principe le plus récent sauf rooling back
Ça me fait penser pour ws2p v2 il serait bon de rajouter un timestamp local au head pour être sur de savoir quel est head le plus récent d’un noeud donné.
Ça coince pour moi… ne se connecte à aucuns nœuds.
2017-11-14T22:51:06+01:00 - error: Unhandled rejection: Error: Request failed: 500
2017-11-14T22:51:06+01:00 - error: Error: Request failed: 500
at Error (native)
at /opt/duniter/node_modules/nnupnp/lib/nat-upnp/device.js:151:27
at Parser.<anonymous> (/opt/duniter/node_modules/xml2js/lib/xml2js.js:199:18)
at emitOne (events.js:96:13)
at Parser.emit (events.js:188:7)
at Object.saxParser.onclosetag (/opt/duniter/node_modules/xml2js/lib/xml2js.js:183:24)
at emit (/opt/duniter/node_modules/sax/lib/sax.js:624:35)
at emitNode (/opt/duniter/node_modules/sax/lib/sax.js:629:5)
at closeTag (/opt/duniter/node_modules/sax/lib/sax.js:889:7)
at Object.write (/opt/duniter/node_modules/sax/lib/sax.js:1436:13)
at Parser.exports.Parser.Parser.parseString (/opt/duniter/node_modules/xml2js/lib/xml2js.js:211:31)
at Parser.parseString (/opt/duniter/node_modules/xml2js/lib/xml2js.js:6:61)
at Request._callback (/opt/duniter/node_modules/nnupnp/lib/nat-upnp/device.js:149:14)
at Request.self.callback (/opt/duniter/node_modules/nnupnp/node_modules/request/main.js:120:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:191:7)
at Request.<anonymous> (/opt/duniter/node_modules/nnupnp/node_modules/request/main.js:633:16)
at emitOne (events.js:96:13)
at Request.emit (events.js:188:7)
at IncomingMessage.<anonymous> (/opt/duniter/node_modules/nnupnp/node_modules/request/main.js:595:14)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
@nay4 merci pour ce retour. Peut tu me partager ta config que j’essaye de voir ce qui peut coincer ? (fichier conf.json dans ~/.config/duniter/NOM_DE_TON_PROFIL_DE_DONNEES)
Tu utilise l’UpnP ?
cat ./.config/duniter/duniter_default/conf.json
{
"currency": "g1",
"endpoints": [],
"rmEndpoints": [],
"upInterval": 3600000,
"c": 0.0488,
"dt": 86400,
"dtReeval": 15778800,
"ud0": 1000,
"stepMax": 5,
"sigPeriod": 432000,
"sigValidity": 63115200,
"msValidity": 31557600,
"sigQty": 5,
"xpercent": 0.8,
"percentRot": 0.67,
"powDelay": 0,
"avgGenTime": 300,
"dtDiffEval": 12,
"medianTimeBlocks": 24,
"httplogs": false,
"udid2": false,
"timeout": 3000,
"isolate": false,
"forksize": 100,
"switchOnHeadAdvance": 3,
"sync": {},
"msPeriod": 5259600,
"loglevel": "info",
"cpu": 0.6,
"prefix": 2,
"nobma": true,
"upnp": true,
"dos": {
"whitelist": [
"127.0.0.1"
],
"maxcount": 50,
"burst": 20,
"limit": 40,
"maxexpiry": 10,
"checkinterval": 1,
"trustProxy": true,
"includeUserAgent": true,
"errormessage": "Error",
"testmode": false,
"silent": false,
"silentStart": false,
"responseStatus": 429
},
"ws2p": {
"uuid": "913b6721",
"privateAccess": true,
"publicAccess": true,
"upnp": true
},
"sigStock": 100,
"sigWindow": 5259600,
"idtyWindow": 5259600,
"msWindow": 5259600,
"rootoffset": 0,
"remoteport": 15278,
"ipv4": "192.168.1.20",
"ipv6": "2a01:e35:8a19:a290:b0d9:e75c:b0ff:247d",
"port": 15278,
"remoteipv4": "",
"remoteipv6": "",
"udTime0": 1488970800,
"udReevalTime0": 1490094000,
"bmaWithCrawler": false,
"proxiesConf": {
"reachingClearEp": "clear",
"forceTor": false
}C’est quoi la manip pour tout mettre dans une fenêtre déroulante ?
@nay4 merci la config me parait bonne. je n’utilise pas UPnP mais cette erreur tu l’avais peut être déjà dans les log lors des versions précédentes, tu a été voir les log juste parce que ton noeud n’établis aucune connexion c’est ça ?
Il faut savoir que c’est normal et que ça peut arriver, surtout si ton noeud démarre après avoir été éteint ou désynchronisé, des fois ton noeud n’arrive pas a établir de connexion tout simplement parce qu’il n’y a de la place nul part. Demande aux membres calculants que tu connais de t’ajouter dans leur liste de privileged (et fait de même avec eux du coup).
Sinon resync manuellement relance et attend, ton noeud retente de se connecter au réseau toutes les 10 min
Surligne le texte et clique sur l’icône </>
1 Like
Effectivement, je suis maintenant connecté à un nœud…
1 Like