Problème de charge des serveurs lors des ĞMarchés

R&D
1

Dans les ĞMarchés, il y a souvent des problèmes de transactions perdues ou qui restent en suspend.

Cela provient en général du fait que certains utilisateurs ont leur Cesium configuré sur un serveur Duniter non synchronisé sur la blockchain majoritaire.

Pour résoudre ce problème, les plus geeks sur les ĞMarchés ont eu la très bonne idée de lancer leur propre serveur, et de demander aux utilisateurs de se connecter dessus.

Mais là, patatra, il semble que toutes les transactions sur le même serveur le surcharge et on assiste à des problèmes de connexion.

Olivier, dans les questions réponses de cette vidéo explique bien le problème rencontré :

Un serveur Duniter n’accepte pas des requêtes trop fréquentes venant de la même adresse réseau. Pour éviter le spam. Ce n’est donc pas un bogue du à la surcharge, mais une sécurité.

Olivier résout cette limitation en configurant son serveur Duniter avec l’IP de la box WIFI utilisée lors du ĞMarché (en ajoutant l’IP de la box dans la section WhiteList du fichier config.json).

Amha, ce problème sera résolu en ayant des clients vraiment p2p (multi-noeuds), capable de répartir les connexions sur les nœuds synchronisés sur la blockchain majoritaire.

Olivier propose d’ajouter au protocole de pouvoir déclarer en Whitelist une IP de son choix pendant une période donnée.

Et vous, avez-vous une idée pour fiabiliser l’utilisation des clients ?

2 Likes
2

Comment cette protection marche-t-elle quand le noeud est derrière un reverse-proxy ? Est-ce que l’adresse du client est correctement identifiée, ou bien au contraire seule l’IP du reverse-proxy est vue ?

3

A mon avis, tu devrais avoir la réponse dans les IP affichées dans les logs Duniter. Mais je ne sais pas si on a des logs en mode debug sur les connexions BMA…

4

C’est l’anti-dos de BMA conçu par cgeek qui est un peu restrictif : 10 requêtes par secondes où 300 requêtes par minute.

BMA utilise le module npm ddos qui supporte le header X-Forwarded-For.

EDIT: en me relisant je me rends compte que ce n’est pas clair. En fait il y a deux couches de protection :

  • une en 1ère ligne gérée par la lib ddos et paramétrable dans le fichier conf.json
  • une en 2ème ligne gérée par cgeek à la main et pas paramétrable, (10 requêtes par secondes où 300 requêtes par minute). La limitation de cette 2ème couche semble être par endpoint et non par IP.

Je ne sais pas quelle couche est trop restrictive, où si c’est les deux.

5

Justement, les logs de duniter affichent l’IP de mon reverse-proxy.