Appendice C. Rilevamento dei duplicati

Appendice C. Rilevamento dei duplicati

Come descritto nella Sezione 9.4, il rilevamento dei duplicati dei record di accounting si basa sugli identificatori di sessione. I duplicati possono comparire per vari motivi:

• Failover su un server alternativo. Quando è richiesta una prestazione vicina al tempo reale, le soglie di failover devono restare basse, il che può aumentare la probabilità di duplicati. Il failover può avvenire sul client o all'interno degli agent Diameter.

• Guasto di un client o agente dopo l'invio di un record dalla memoria non volatile, ma prima della ricezione di un ACK a livello applicazione e della cancellazione del record da inviare. Ciò comporterà la ritrasmissione del record poco dopo il riavvio del client o dell'agente.

• Duplicati ricevuti dai gateway RADIUS. Poiché il comportamento di ritrasmissione di RADIUS non è definito in [RFC2865], la probabilità di duplicazione varia secondo l'implementazione.

• Problemi di implementazione e errata configurazione.

Il flag T è usato come indicazione di un evento di ritrasmissione a livello applicazione, ad esempio a causa del failover su un server alternativo. È definito solo per i messaggi di richiesta inviati da client o agent Diameter. Ad esempio, dopo un riavvio, un client potrebbe non sapere se ha già tentato di inviare i record di accounting nella memoria non volatile prima del riavvio. I server Diameter POSSONO usare il flag T come ausilio nell'elaborazione delle richieste e nel rilevamento di messaggi duplicati. Tuttavia, i server che lo fanno DEVONO garantire che i duplicati siano trovati anche quando la prima richiesta trasmessa arriva al server dopo quella ritrasmessa. Può essere usato solo quando non è stata ricevuta alcuna risposta dal server per una richiesta e la richiesta viene inviata di nuovo (ad esempio per failover su un peer alternativo, ripristino del peer primario o reinvio da parte del client di un record memorizzato dalla memoria non volatile dopo il riavvio di un client o agente).

In alcuni casi, il server di accounting Diameter può ritardare il rilevamento dei duplicati e l'elaborazione dei record fino a una fase di post-elaborazione. A quel punto i record saranno probabilmente ordinati in base al User-Name incluso e l'eliminazione dei duplicati è semplice. In altre situazioni può essere necessario un rilevamento in tempo reale dei duplicati, ad esempio quando sono imposti limiti di credito o si desidera il rilevamento delle frodi in tempo reale.

In generale, solo la generazione di duplicati dovuta al failover o al reinvio di record in archiviazione non volatile può essere rilevata in modo affidabile dai client o agent Diameter. In tali casi, il client o l'agent Diameter può contrassegnare il messaggio come possibile duplicato impostando il flag T. Poiché il server Diameter è responsabile del rilevamento dei duplicati, può scegliere se usare il flag T per ottimizzare il rilevamento. Poiché il flag T non influisce sull'interoperabilità e alcuni server potrebbero non averne bisogno, la generazione del flag T è RICHIESTA per client e agent Diameter, ma i server Diameter POSSONO implementarla.

Come esempio, di solito si può presumere che i duplicati compaiano entro una finestra temporale pari alla più lunga partizione di rete o guasto di dispositivo registrata, forse un giorno. Quindi solo i record in questa finestra devono essere esaminati all'indietro. In secondo luogo, tecniche di hashing o altri schemi, come l'uso del flag T nei messaggi ricevuti, possono eliminare la necessità di una ricerca completa in questo insieme salvo casi rari.

Di seguito un esempio di come il server può usare il flag T per rilevare richieste duplicate.

Un server Diameter PUÒ controllare il flag T del messaggio ricevuto per determinare se il record è un possibile duplicato. Se il flag T è impostato nella richiesta, il server cerca un duplicato entro una finestra temporale di duplicazione configurabile all'indietro e in avanti. Ciò limita la ricerca nel database ai record in cui il flag T è impostato. In una rete ben gestita, partizioni di rete e guasti dei dispositivi saranno presumibilmente eventi rari, quindi questo approccio rappresenta un'ottimizzazione sostanziale del processo di rilevamento dei duplicati. Durante il failover, è possibile che il record originale arrivi dopo quello contrassegnato con il flag T, a causa delle differenze nei ritardi di rete lungo il percorso tra trasmissione originale e duplicata. La probabilità aumenta al diminuire dell'intervallo di failover. Per rilevare duplicati fuori ordine, il server Diameter dovrebbe usare finestre temporali all'indietro e in avanti quando esegue il controllo dei duplicati per la richiesta contrassegnata con T. Ad esempio, per concedere tempo all'uscita del record originale dalla rete e alla sua registrazione sul server di accounting, il server Diameter può ritardare l'elaborazione dei record con flag T fino a che non è trascorso un periodo TIME_WAIT + RECORD_PROCESSING_TIME dopo la chiusura della connessione di trasporto originale. Dopo tale periodo, può confrontare i record contrassegnati con T con il database con relativa certezza che i record originali, se inviati, siano stati ricevuti e registrati.