Quanto tempo è necessario per consentire l'inclinazione dell'orologio?

Devi farlo basandoti su ciò che vedi nel tuo sistema. I due approcci di base sono di farlo una volta o di rendere il tuo codice aggiustato al volo. Il primo è ovviamente molto più facile da fare ma un po 'meno resiliente.

Farlo una volta significa registrare la differenza di tempo per ciascun paio di server per un po 'e vedere cosa ottieni. Questo potrebbe richiedere un po 'di tempo, dal momento che si desidera vedere se si risincronizzano a NIST o simili a intervalli. Ma anche molto presto dovresti avere un'idea se le differenze di orario sono coerenti o meno. Quindi hard-code in un valore ragionevole. Il salto più grande è probabilmente quello di correzione, ma potresti non vederlo mai accadere, quindi dovrai indovinare "il nostro sito è tranquillo durante la notte ma è probabile che il salto avvenga tra le 2:00 e le 6:00 AEST" è probabile).

La versione più resiliente ma più codificata è quella di fare quanto sopra ma mappare l'offset effettivo ai valori osservati più di recente. Se il tuo timeout è di un paio d'ore e vedi che l'altro sistema è andato alla deriva da un secondo al mese, costruisci quello alla tua pre-scadenza. Diventa complesso solo quando stai cercando di indovinare il punto in cui l'altro sistema salterà un paio di secondi indietro a causa di una correzione mensile dell'orologio.

Penso che quest'ultimo sia eccessivo se non stai osservando i salti entro un fattore pari a 10 del tempo di scadenza totale. A quel punto vorrai buttare via il 20% del tempo totale, che è un aumento del 25% del traffico OAuth. Quindi potrebbe essere utile scrivere più codice nel tentativo di ridurlo. Ma anche in questo caso, potrebbe non essere il più grande risparmio di larghezza di banda che puoi ottenere per il tuo tempo di programmazione.

Se entrambi i server sono sincronizzati con tempo NIST o qualcosa di simile accurato, la differenza dovrebbe essere trascurabile (soggetto a ritardi di trasmissione tra i due server, secondi o meno).

Se i server stanno mantenendo il proprio tempo e non sono gestiti correttamente, la differenza può essere notevole (minuti o più). Dipende se i server dispongono di un software decente del sistema operativo che si aggiorna automaticamente su Internet periodicamente.

Gli orologi di tutti i dispositivi che sono collegati a Internet non sono mai più di una piccola frazione di secondo. Anche se si sincronizzano solo una volta al mese, non andranno molto alla deriva, e se prendono spunto dalla rete elettrica (che viene mantenuta ad una frequenza molto precisa), potrebbero non andare affatto alla deriva. I buoni orologi basati su un cristallo di quarzo si spostano di qualche secondo al mese. I computer che sono cinque minuti di pausa sono quelli che non vengono mai aggiornati.

Questo è il modo in cui probabilmente lo risolverò, se possibile:

• Ottieni l'ora dal server di destinazione (che convaliderà il token) e calcolerà la differenza con l'ora dal server che ha emesso il token. Imposta un timer per ottenere il token prima che scada in base all'ora sul server target .

  • Aggiungi un po 'di margine per le chiamate di andata e ritorno per ottenere un nuovo token e per la chiamata di andata e ritorno per controllare l'ora.

  • Aggiungi alcuni margini per i tentativi nel caso in cui il server sia inattivo. Ad esempio, se il token deve essere aggiornato prima delle 8:22:20, potresti voler iniziare alle 8.21: 20 con l'ipotesi che puoi provare tre volte (in caso di errori di rete / connettività) con un intervallo di 15 secondi e avere ancora 15 secondi per il margine delle chiamate di andata e ritorno. È possibile aumentare i margini se la durata del token è espressa in ore anziché in minuti.

  • Quando il codice ottiene un token e capisce che dovrà essere aggiornato troppo velocemente (diciamo sotto una certa soglia, come < 50% della durata del token o 5 minuti), dovrebbe generare un avviso perché i server stanno diventando veramente fuori sincrono.

  • Nel calcolo, il codice dovrebbe normalizzare tutto il tempo allo stesso fuso orario, come ad esempio UTC, o il codice andrà tutto whacky.

  • Su alcune piattaforme, ottenere il tempo di un server di destinazione è piuttosto banale. Su altri, potrebbe essere necessario esporre i metodi web per farlo, ma si spera che dovrebbe andare bene.

• Pur avendo la logica per ottenere un token di aggiornamento, penso che il tuo codice dovrebbe ottenere un token di accesso se la finestra per ottenere il token di aggiornamento è passata, ma genera un avviso in modo che il codice possa essere corretto. Se l'operazione non è critica nel tempo, potresti volere che fallisca con garbo se non è stato possibile ottenere un token di aggiornamento, ma dovrebbe comunque generare un avviso per correggere il codice.