Torna al blog Connettività

Backoff e jitter nei nuovi tentativi SMS: come recuperare senza sovraccaricare la route

Una guida operativa al pattern di backoff nei nuovi tentativi e ai suoi limiti: le evidenze disponibili non consentono di prescrivere parametri o regole specifici per gli SMS.

Illustrazione concettuale di richieste ripetute con pause crescenti

Perché non conviene riprovare subito

Il backoff nei nuovi tentativi è un pattern documentato per ripetere le operazioni non riuscite e contribuire alla stabilità. Le evidenze disponibili non specificano parametri né dimostrano risultati concreti per le operazioni SMS.

Non è possibile dedurre da queste evidenze in quale punto di un'operazione SMS si sia verificato un errore, come interpretare una risposta specifica o se sia opportuno ripetere una richiesta. Per prendere decisioni specifiche servono fonti tecniche applicabili al protocollo e al provider.

  • Le evidenze disponibili supportano solo il pattern generale di nuovi tentativi con backoff in caso di errore.
  • Non consentono di fissare valori, classificare le risposte SMS o stabilire regole per i nuovi tentativi in base al protocollo o al provider.
  • Il pattern non va presentato come garanzia di recupero o di consegna.
Perché non conviene riprovare subito

Classificare il risultato prima di decidere

Le evidenze fornite non consentono di definire come classificare le risposte di invio SMS come permanenti, temporanee o incerte. Non giustificano nemmeno una regola generale per decidere se un risultato richieda un nuovo tentativo.

Per descrivere tale classificazione o consigliare azioni servono fonti primarie applicabili e verificabili. In loro assenza, evita di presentare un'interpretazione specifica delle risposte SMS come una regola supportata dalle fonti.

  • Le evidenze disponibili non definiscono categorie di risposte SMS né le azioni associate.
  • Non dedurre una regola per i nuovi tentativi da informazioni che non sono supportate dalle fonti fornite.
Classificare il risultato prima di decidere

Stabilire chi è responsabile dei nuovi tentativi

Le evidenze fornite non supportano raccomandazioni specifiche per coordinare i nuovi tentativi tra un'applicazione, un livello intermedio e un provider SMS. Non consentono di determinare in che modo questi livelli gestiscano una richiesta o quale effetto avrebbe la sua ripetizione da parte di più di un livello.

Qualsiasi affermazione sulla responsabilità dei nuovi tentativi o sul coordinamento tra componenti richiede fonti tecniche applicabili. Le informazioni disponibili supportano soltanto il pattern generale dei nuovi tentativi con backoff.

  • Sulla base delle evidenze fornite non è possibile stabilire quale componente debba eseguire i nuovi tentativi.
  • Non è possibile definire un limite complessivo di tentativi o un intervallo temporale specifico per gli SMS.

Scegliere backoff, attesa massima e jitter

La fonte disponibile descrive il pattern dei nuovi tentativi con backoff, ma non fornisce parametri né raccomandazioni dettagliate. Pertanto, non giustifica una formula, un limite massimo, un'attesa iniziale o una strategia di jitter per un'operazione SMS.

Le evidenze fornite non consentono nemmeno di prescrivere una configurazione universale. Non presentare numeri o formule come raccomandazioni verificate per gli SMS.

  • Le evidenze disponibili non supportano parametri specifici di backoff o jitter.
  • Con le fonti fornite non è possibile raccomandare un numero di tentativi o un'attesa massima.
  • La fonte citata tratta il pattern in termini generali e non attesta risultati specifici per gli SMS.

Allineare i nuovi tentativi alla validità del messaggio

Le evidenze fornite non stabiliscono come collegare i nuovi tentativi SMS alla validità di un messaggio, compresi gli OTP e i messaggi transazionali. Non consentono di raccomandare una finestra di validità o regole per interrompere i tentativi.

Queste decisioni non possono essere presentate come indicazioni tecniche supportate dalle informazioni disponibili.

  • Le evidenze disponibili non definiscono tempi di validità per gli SMS né regole per i nuovi tentativi basate su di essi.
  • Non affermare che una specifica politica di validità sia convalidata dalle fonti fornite.

Prevenire i duplicati con correlazione e verifica dello stato

Le evidenze fornite non supportano affermazioni su idempotenza, correlazione, deduplicazione o consultazione dello stato di un invio SMS. Non consentono di garantire che una determinata funzione sia disponibile o di descriverne il comportamento.

Per fornire indicazioni su questi meccanismi servono fonti primarie applicabili e verificabili. In loro assenza, evita di affermare che ripetere una richiesta sia sicuro o che un identificativo prevenga i duplicati.

  • Le evidenze disponibili non confermano funzionalità di idempotenza o consultazione dello stato per gli SMS.
  • Non presentare la correlazione o la deduplicazione come funzionalità garantite.
  • Con le fonti fornite non è possibile prescrivere un'azione per risultati incerti.

Distinguere gli errori di trasporto, le risposte di invio e i DLR

Le evidenze fornite non consentono di descrivere regole di protocollo per interpretare gli errori di trasporto, le risposte di invio o i DLR. Non permettono nemmeno di stabilire quali conclusioni si possano trarre dalla mancata ricezione o dalla ricezione di un DLR.

Non presentare interpretazioni specifiche degli stati DLR come verificate dalle fonti disponibili. Per farlo servono fonti primarie applicabili.

  • Le evidenze disponibili non supportano regole specifiche sulle risposte SMS o sugli stati DLR.
  • Non attribuire a un DLR la conferma indipendente della ricezione sul dispositivo.
  • Non dedurre l'esistenza di una regola per i nuovi tentativi dalla mancata ricezione di un DLR.

Registrare i tentativi per verificare le decisioni e diagnosticare i cicli

Le informazioni disponibili non giustificano una specifica di registri o metriche per i nuovi tentativi SMS. Consentono però di mantenere un'importante distinzione editoriale: il pattern generale di backoff, da solo, non costituisce una prova di risultati specifici per gli SMS.

Non presentare un elenco di campi, avvisi o politiche di registrazione come raccomandazione verificata dalle fonti fornite.

  • Le evidenze disponibili non determinano quali campi o metriche registrare per un'operazione SMS.
  • Le fonti fornite non consentono di raccomandare politiche specifiche per la verifica dei nuovi tentativi SMS.
FAQ

Domande frequenti

Quali errori SMS richiedono un nuovo tentativo?

Le evidenze fornite non consentono di stabilire quali risposte SMS richiedano un nuovo tentativo. L'estratto disponibile supporta solo il pattern generale dei nuovi tentativi con backoff in caso di errore.

Quali valori di backoff e jitter conviene usare?

Le fonti disponibili non forniscono parametri di backoff né raccomandazioni sul jitter per gli SMS. Non è possibile indicare valori specifici come raccomandazioni verificate.

Un timeout significa che l'SMS non è stato inviato?

Le evidenze fornite non consentono di determinare che cosa significhi un timeout in un'operazione SMS né quale azione sia appropriata. Servirebbero fonti primarie applicabili all'interfaccia e al provider.

Un DLR conferma che l'utente ha ricevuto l'SMS?

Le fonti fornite non consentono di interpretare gli stati DLR né di confermare che cosa dimostrino. Senza evidenze applicabili, un DLR non va presentato come verifica indipendente della ricezione sul dispositivo.

Fonti consultate

  1. Patrón de reintento con retrocesoAmazon Web Services
  2. HTTP Semantics (RFC 9110)IETF
  3. SMPP v3.4 Issue 1.2SMPP Developers Forum