2013-06-26 21 views
1

我試圖實現一個簡單的同步解決方案來傳播我的應用程序和我的服務器的各種實例之間的一些設置。對這些設置的更改將不經常發生,只發生在客戶端上。我希望事情合理而不會過分。基於時間的iOS同步應用程序

我的策略是跟蹤設備上未同步的更改,並在同步時將這些更改發佈到服務器。服務器應該能夠拒絕在該設置的上次已知同步之後發生的更改。爲了實現這一點,應用程序會爲每個設置存儲一個「更新」日期,服務器會將它與它存儲的類似字段進行比較,以便在其側面進行相同的設置。如果客戶的日期早於最新的設置同步服務器知道(來自不同設備),則該設置的同步將被拒絕。

最後(有希望)是爲了解決客戶端和服務器時鐘之間的差異。

我最初的想法是發送客戶當前的本地日期時間(與更新的設置一起)。收到後,服務器會將客戶的時間與自己的時間進行比較,並知道如何調整客戶設置上的「更新」時間戳。原則上這聽起來很合理,但我如何解決以下兩個問題?

  • 如果客戶端設備的時鐘在更新設置後嘗試同步之前更改,該怎麼辦?
  • 誰知道同步請求需要多長時間才能到達服務器?所以當它收到時,客戶端提供的'系統時鐘'實際上只有幾秒鐘或幾分鐘。
+1

閱讀:與[Vector Time Pairs]同步(http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-650.pdf)。不需要時鐘,但可以選擇使用時間來解決衝突。 –

+0

我已經嘗試過幾次閱讀這個文檔,但沒有太多沉入,但是無論如何感謝。我會最終再試一次。認爲這可能是爲了我的目的矯枉過正。 –

+1

我同意。這是一個困難的閱讀,但我已經實現它在系統之間同步數據。一旦你瞭解它,編碼就不難,而且效果很好。 –

回答

0

你應該做的一切在UTC方面避免時區問題。這並沒有解決用戶時鐘設置不正確的問題,因此您可能需要在數據更新時檢入服務器以驗證實際時間。如果您沒有網絡連接,將會有一些難以處理的情況。有時你能做的最好的事情就是檢測它們並告訴用戶風險。

相關問題