Prière de configurer les régions

Ça bouge sur le mesh, encore!

Une nouvelle proposition de MeshCore Canada a été publiée. Nous pensons que tous les relais de la province devraient l'adopter pour réduire le bruit entre les régions. Il s'agit d'une proposition en plusieurs phases qui, au départ, n'aura pas d'impact significatif sur les usagers à part pour le traffic entre les régions, puisqu'il risque de séparer Québec de Montréal, à moins qu'une région soit assignée au canal de communication.

Ottawa a déjà commencé à déployer ceci et s'est déjà séparé du mesh de Montréal avec ce mécanisme.

Pour un relais dans la grande région de Montréal, prière d'appliquer la configuration suivante:

region def yul|* qc|* onqc|* can|* na
region allowf *
region default yul
region save

D'autres configurations ont requises pour des relais à Québec, ainsi que les relais limitrophes entre deux régions.

Voir plus bas pour d'autres exemples et explications!

Choisir la bonne configuration¶

Les régions peuvent être complexes, mais la décision est assez simple. Il s'agit de répondre à ces quelques questions:

1. dans quelle région Meshmapper se trouve le relais? (pour la grande région de Montréal, par exemple, il s'agit de yul, pour Québec, c'est yqb)
2. est-ce que le relais route des messages de d'autres régions? (pour un relais à Shawinigan connectant yul et yqb, ou le relais YQB-Belair à Québec, la réponse est oui!)
3. si oui, est-ce que le relais doit router des messages de d'autres régions (par exemple, un relais à Trois-Rivières voudra probablement relayer les messages de yul et yqb)

La Phase 1: repeater setup de la proposition MeshCore Canada vous guide assez bien au travers de toutes ces étapes, mais nous allons faire un résumé avec quelques exemples ici.

On assume ici un relais roulant MeshCore 1.16 ou plus. Sinon, suivre la proposition qui a quelques exemples pour des versions plus anciennes.

Ce guide assume également que vous n'avez aucune région déjà configurée. Vous pouvez le vérifier en roulant la commande region, qui devrait seulement retourner *^ F:

> region
*^ F

Relais de ville à Montréal¶

Voici la configuration la plus simple, donnée comme exemple en introduction ci-haut, pour un répéteur dans une ville comme Montréal:

region def yul|* qc|* onqc|* can|* na
region allowf *
region default yul
region save

Ceci fait les 4 chose suivantes

1. configuration du relais pour les messages des régions locales (yul), la province (qc), le corridor Ontario-Québec (onqc), et le reste du Canada (can) ainsi que l'amérique du nord (na)

2. tout de même permettre le trafic sans région (allowf *)

3. envoyer des annonces avec la région locale (default yul)
4. enregistrer la configuration

Répéteur de ville à Québec¶

Même chose, mais dans la ville de Québec:

region def yqb|* qc|* onqc|* can|* na
region allowf *
region default yqb
region save

Voir ci-haut pour une explication: la seule différence est qu'on configure le relais pour yqb plutôt que yul.

C'est la configuration qui devrait être initialement déployée sur YQB-Belair pendant que les gens commencent à utiliser les régions avec leurs compagnons dans la ville de Québec.

Relais en bordure de Québec¶

Voici la configuration qui devrait éventuellement être déployée sur un relais comme YQB-Belair:

region def yqb|* qc|* onqc|* can|* na
region denyf *
region default yqb
region save

Éventuellement ici, car nous comprenons que YQB-Belair est un relais clé dans la région. La configuration denyf * empêcherait au relais de transmettre les messages sans région, ce qui pourrait être très perturbant.

Donc, pour l'instant, commençons avec allowf * jusqu'à ce que les régions soient adoptées plus largement.

Shawinigan edge repeater¶

Tout comme le relais limitrophe ci-haut, il serait peut-être mieux de commencer avec une configuration allowf * qui permettrait de transmettre les messages sans région. Mais ultimement, un relais entre les régions yul et yqb devrait avoir cette configuration:

region def yul|* yqb|* qc|* onqc|* can|* na
region denyf *
region default yqb
region save

La seule différence avec le relais de Québec est l'ajout de la région yul ce qui signifie que le relais va passer les messages des deux régions, yul et yqb.

Notez que nous assumons ici que le relais se considère comme faisant partie de la région yqb, mais s'il se considèrerait dans la région yul, la seule différence serait de changer la ligne default qui serait alors:

region default yul

Et encore une fois, ceci est une configuration un bring agressive qui pourrait être perturbante. Il est mieux de commencer avec allowf * et basculer lorsque les compagnons ont adopté les régions.

Compagnons¶

Pour l'instant, rien ne change pour les compagnons. Tous (ou presque!) les relais dans une région doivent configurer les régions avant que les compagnons puissent les utiliser car un relais non-configuré va simplement ignorer les paquets avec régions!

La phase 2 de la proposition est présentemnent prévue pour Janvier 2027, mais il est possible qu'on doive faire ces changements plus tôt si nous avons toujours des problèmes de flood.

En phase 2, les compagnons commencent à régler une régions par défaut (utilisée pour les DMs) et régler une région pour chaque canal (que nous documenterons dans notre list des canaux).

Voici un exemple de configuration des canaux, en assumant que vous êtes dans la région yul (sinon remplacer yul avec yqb par exemple):

Qui?¶

Ces réglages ont été testés avec les opérateurs-trices et relais suivants:

• anarcat: YUL-Little-Italy, YUL-Poly, YUL-Plateau-Ouest-R1
• GrosTonyMobil: YUL Mont Lanaudière, GrosTony RPT2
• T MeshPocket: YUL-Tétreaultville
• VA2DG: VA2DGR, VE2TOW, VE2RSM
• Smog: YMX-J6Z, YMX-J6Y
• lavamind: YUL-Viauville
• zivior: YUL-LucienLallier
• MeshCourte: Villeray, Villeray-Nord

Tous ont été réglés en mode "ville" sauf note contraire.

Pourquoi?¶

Ceci règle un problème similaire que la proposition floods en ce qu'on tente de limiter la quantité de messages transmise par les relais.

Les régions ont déjà été déployée à Ottawa, qui s'est séparée du réseau à moins que les messages soient marquées par la bonne région. Donc si nous voulons une communication entre ces villes, nous devons commencer à utiliser les régions.

Configurer les régions va également permettre aux gens de se familiariser avec l'outil. Dans certaines circonstances, un tel mécanisme pourrait être utile pour permettre à une communauté de communiquer localement sans envoyer leurs messages au travers le mesh entier.

Questions?¶

Quelle est la phase 3?¶

Il y a une phase 1 et 2, quelle est la phase 3?

La phase 3 est un mécanisme de dernier recours que nous pouvons utiliser dans une ville pour liiter le nombre desauts ("hops") pour les messages sans régions, avec la configuration:

set flood.max.unscoped 3

C'est une version plus douce que denyf * en ce que les relais continuent de passer les messages pour quelques hops, puis cessent.

Est-ce que je peux ajouter d'autres régions?¶

Puis-je, disons, ajouter YUL, Yul or YOLO à la liste des régions au cas où les gens se trompent dans l'orthographe?

De grâce, non! MeshCore a un mécanisme de découverte qui permet aux compagnons de découvrir les régions. Ajouter ces variations va simplement ajouter de la confusion et de l'ambiguïté sur les bonnes régions à configurer.

Commentaires¶

Dans tous les cas, nous aimerions avoir vos commentaires sur cette proposition par nos points de contact habituels et la merge request sur Codeberg.

Cet article est également disponible avec l'URL court https://lora.reseaulibre.ca/fr/regions/ pour partager plus facilement sur le mesh.