Skip to main content

​
La table qui n’a jamais été au moindre coût

Un nom de fonction écrit et non reconnu retombe sur NORMAL. ->function(LRC) est une transposition que n’importe qui peut faire, et la table route alors en premier-correspondant alors que son auteur croit qu’elle route selon le prix. Chaque tarif fournisseur qu’elle contient est ignoré, et chaque message part vers la règle qui se trouve en haut.Le système journalise routing.table.unknown-function et continue de fonctionner. Ce repli est délibéré : refuser à cet endroit refuserait tout l’ensemble de tables, et un nom mal tapé ne devrait pas mettre le routage hors service. Vérifiez le nom caractère par caractère, et vérifiez le journal.
Il existe exactement deux fonctions, NORMAL et LCR. Une table qui ne déclare aucune fonction est NORMAL.
Une troisième fonction, RC, a été supprimée dans V1.28.0. Elle figurait dans l’énumération, elle était autorisée par la contrainte de base de données, et elle était décrite dans le panneau. Or aucun branchement ne l’utilisait, donc une table réglée sur RC routait comme NORMAL alors que toutes les surfaces qu’un opérateur pouvait consulter disaient autre chose. Les lignes existantes sont réécrites en NORMAL, ce qu’elles faisaient déjà.

​
Ce qui change

Une table NORMAL s’arrête à la première règle qui correspond, ce qui fait de l’ordre du fichier la priorité. Une table LCR parcourt toutes les règles, traite les correspondances comme des alternatives plutôt que comme une chaîne de repli, et laisse le seul tarif dans rates.conf décider.
L’ordre des règles n’a aucune importance à l’intérieur d’une table LCR. Déplacer une règle vers le haut ne la rend pas préférée, et placer un attrape-tout en premier ne masque rien de ce qui suit. Si vous réorganisez les règles ici pour changer le comportement, vous modifiez le mauvais fichier. Ce sont les tarifs de coût qui décident.

​
Comment un gagnant est choisi

1

Toutes les règles de la table sont parcourues

Aucune sortie anticipée. Une règle dont la cible est une autre table est ignorée avec un avertissement. Un coût imbriqué ne peut pas être comparé, et router à un prix inconnu serait pire que ne pas y router.
2

Les fournisseurs morts disparaissent

Une cible qui est en panne, suspendue ou qui n’accepte pas est ignorée, de sorte que le suivant moins cher porte le trafic. C’est le même signal qu’utilise un groupe ; voir Fournisseurs pour les quatre états.
3

Les survivants sont tarifés

Chaque candidat restant est tarifé pour le produit de ce message par rapport au côté coût de rates.conf. Le moins cher l’emporte.
4

Un candidat sans tarif est le dernier recours

Un fournisseur sans tarif de coût correspondant est mis de côté et utilisé uniquement si rien d’autre ne correspond, en journalisant No candidate in least-cost table … has a rate.
Une ligne de tarif manquante dégrade plutôt qu’elle ne bloque. Refuser de router un message non tarifé transformerait une ligne oubliée dans rates.conf en panne ; la préférer enverrait tout par le fournisseur le moins configuré. Le dernier recours est la seule réponse qui n’est ni l’un ni l’autre.Il vaut tout de même la peine d’être alerté, car un fournisseur qui gagne du trafic sur un tarif manquant le gagne à une marge inconnue. Voir Comment fonctionne la tarification.

​
Deux choses refusées d’emblée

Les deux sont refusées au chargement, en bloc, car aucune n’a d’état partiel qui route de la façon que quiconque avait prévue. L’ensemble de tables cesse de se mettre à jour jusqu’à ce que ce soit corrigé.
Le moindre coût choisit par le prix et un groupe choisit par la politique. Étendre les membres en candidats tarifés écarterait silencieusement la politique, et un groupe pondéré n’a aucun sens à donner à une comparaison de prix.Utilisez l’un ou l’autre dans une table donnée : un groupe si vous voulez du failover et un partage proportionnel, une table LCR si vous voulez le fournisseur vivant le moins cher.
La résolution est table, puis groupe, puis worker, donc l’un des deux serait silencieusement inaccessible. Renommez l’un d’eux.

​
Copier-et-continuer n’a pas de sens ici

+copied marque une règle comme « ajouter cette cible et continuer à parcourir ». Une table LCR parcourt déjà toute la table puis choisit un candidat le moins cher, il n’y a donc rien qu’une copie puisse contourner. Le panneau le dit plutôt que de laisser le drapeau paraître significatif.

​
Diagnostiquer un choix

outSms.routing.trace, réglé sur un numéro de série ou un identifiant de compte, explique quelles règles ont correspondu. La sélection elle-même — quel candidat a gagné et à quel tarif — est journalisée sous outSms.routing.debug, qui n’est utilisable que sur une passerelle inactive ; voir Comment fonctionne le routage. Si une table LCR envoie tout vers un seul fournisseur, vérifiez dans cet ordre :
  • Le nom de la fonction est-il orthographié LCR ?
  • Les autres candidats ont-ils bien un tarif de coût, pour le produit de ce message ?
  • Les autres candidats acceptent-ils ? Un fournisseur qui est bindé mais non transmettable est ignoré.
Les tarifs sont configurés séparément ; voir rates.conf et routingTable.conf.