Délai d'attente avant de devenir membre


#1

J’ai reçu 5 promesses de certifications depuis le 1er septembre (j’en ai eu une 6ème depuis). Le temps passe, et la date provisionnelle pour que je devienne membre ne cesse de reculer (en gros, à une date donnée, la prévision de WotWizard est 13 jours plus tard).

Je pense comprendre comment fonctionne l’algorithme (dès qu’on peut faire rentrer un membre, on le fait, sinon on envoie les certifications disponibles vers les membres existants), mais je me demande si on ne pourrait pas faire rentrer un peu de FIFO dans cet algorithme. Cela augmenterait peut-être le délai en moyenne, mais cela donnerait plus de visibilité sur le temps à attendre. J’ai l’impression qu’il est possible que quelqu’un ne rentre jamais (ou en moins de deux mois) parce que les promesses de certification sont toujours retardées.

Est-ce un phénomène récent, ou c’est comme cela depuis le début ?


Certification [disponible] qui ne l'est plus le lendemain (pourtant pas expirée
#2

Ah oui mon pauvre, tes certificateurs sont de gros certificateurs et pas phasés (en gros leur certif est accordée à un dossier complet entre temps à chaque fois).
ça throttle quoi. Malheureusement, là, même pas de notion de FIFO à tenir, ce n’est pas l’aléatoire qui gène, c’est que il y a toujours quelqu’un qui passe entre temps.

La seule solution serait que tes certificateurs ne remettent pas de nouvelle certification en piscine le temps que tu rentres.


#3

C’est vrai qu’une solution à ce problème est de choisir quand émettre sa certification.

Par FIFO, je voulais dire que dès que quelqu’un a 5 certifications et qu’il satisfait la règle de distance, il rentre dans une file d’attente et ces certifications sont bloquées : seules les certifications données aux personnes précédentes dans la file seront prioritaire. On peut donc prédire précisément à quelle date cette personne rentrera. On peut même faire pareil pour les certifications additionnelles quand quelqu’un est déjà membre (les mettre dans la même file).


#4

Potentiellement, ça ralentirait le rythme général !

J’aime bien le système actuel moi et aussi parce qu’il encourage effectivement à ne pas lancer 30 certifications d’un coup.


#5

Oui, j’ai bien conscience que cela ralentirait les choses. Faire baisser le variance a un prix, souvent l’espérance :wink:


#6

Une telle FIFO ne pourrait être garantie, car il n’existe pas de garantie d’avoir des piscines vraiment identiques : il suffit qu’un seul nœud ne voit pas le dossier complet pour qu’il décide d’agir autrement. Sans compter sur ceux qui vont directement modifier le code rien que pour casser cet algorithme de façon volontaire :slight_smile:


#7

C’est pas faux. Mais c’est pas déjà le cas aujourd’hui ? Et n’as-t-on pas plus de chance d’avoir les vieilles certifications en piscine que les nouvelles ?


#8

Oui n’importe qui peut modifier le code de son nœud quand il veut, dès aujourd’hui :slight_smile:

Disons que oui, dans le sens où une ancienne certification a eu beaucoup plus d’occasions d’être synchronisée.


#9

J’imagine, mais ce n’est pas cela que je voulais dire. L’algorithme qui aujourd’hui favorise les nouveaux membres par rapport aux certifications vers des membres existants dépend lui-aussi de la piscine.

Maintenant je comprends que l’on veuille les règles les plus simples possibles et le plus de déterminisme possible pour limiter les forks.


#10

Ah oui tout à fait, cela dit l’algo favorise les nouveaux membres et les certifications nécessaires que pour le bloc à forger, il ne bloque pas de certifications sur 1 ou plusieurs blocs comme tu le suggères pour une FIFO. En fait celui-ci ne bloque jamais une certification prête à passer.

Avoir un algo qui ferait un tel blocage est juste plus difficile à tenir sur N blocs, ou le contrôle n’est plus local au nœud mais bien porté à l’ensemble du réseau.


#11

OK, c’était une mauvaise idée.

Peut-être que la page https://duniter.org/fr/wiki/devenir-membre/ pourrait contenir plus que la licence, et expliquer qu’il peut y avoir un délai entre la réception des certifications et le moment où on devient membre. Sans https://g1-monit.elois.org/willMembers?lg=fr et WotWizard, je n’aurais aucune idée de ce qui se passe.


#12

J’ai fait cet ajout : https://duniter.org/fr/wiki/devenir-membre/#suivi-de-linscription


#13

C’est top, merci.


#14

Par avance je demande pardon à @elois pour mettre encore plus en avant g1-monit, dont le serveur est déjà submergé de requêtes pour cet outil visiblement très apprécié :slight_smile:


#15

On peut peut-être offrir un loadbalancing sur doppler à Elois pour absorber une partie de la charge ?


#16

Pour l’instant j’ai déjà mis en place un load balancing sur 3 instances, ça allège un peu : la mienne, celle de mlo et celle de @Pafzedog (merci). @cgeek est ce que je peut rajouter la tienne, avec un poids faible du genre 1 ip sur 10 ?


#17

Oui, enfin faut d’abord tester que mon module fonctionne bien et est à jour.

edit : ça à l’air bon, là.


#18

hop c’est fait. C’est un mode ip-hash donc une ip sur 10 te sera attribué, ce qui ne correspondra pas forcement à 1/10ème des requêtes cela dépend de l’activité des ip qui te sont attribués. Surveille ton serveur et dit moi si ya trop de charges je t’enleverrai :wink:


#19

Simple question de curiosité: est-ce que g1-monit peut-être installé sur un Raspberry pi? Si oui, pouvons nous faire des sites miroir?

PS: Je pense que vous connaissez déjà “haproxy” sous linux.


#20

@stephane je n’ai jamais tester sur un raspi mais ça devrait fonctionner. Il te suffit d’ouvrir une connextion ssh sur un raspi qui tourne duniter-server et de faire :

duniter plug duniter-currency-monit@0.4.x
duniter stop
duniter currency-monit // équivalent de duniter start mais avec monit

Puis de te rendre sur localhost:10500