2014-07-04 93 views
0

我創建了一個Android應用程序,允許用戶發送消息給其他用戶。爲了達到這個目的,我使用了GCM。因此,用戶可以使用Web服務(使用Web API框架開發)發送消息,將消息保存在遠程數據庫(SQL Server)上,並聯系GCM服務器以向接收方傳遞GCM消息。GCM應用服務器內部網絡服務

可能發生未接收到GCM的消息,例如,因爲GCM服務器存在臨時不可用狀態。所以谷歌建議使用指數退避嘗試重新發送。這是我的體系結構的一個問題,因爲我從另一個WS(我創建的那個,從用戶向其他用戶發送消息時使用的那個)中調用GCM。如果我嘗試使用指數退避,我的外部WS應該是活動的,因爲GCM返回有效的響應。

因此,似乎從另一個Web服務內部調用GCM Web服務並不是一件好事。這是正確的嗎?你能給我任何建議嗎?什麼是使用GCM的IM應用程序最常見的體系結構?

回答

0

在我看來,你的問題是,你的Web服務發送消息到GCM是同步的(至少這是我根據你的問題)。即,它從客戶端收到請求,向GCM服務器發送請求,並在從GCM服務器獲得響應後向客戶端返回響應。

我建議你改變架構。您的Web服務應該接收來自客戶端的消息,將其存儲在數據庫中並向客戶端返回響應。

服務器中的一個單獨的線程應定期喚醒,以查看數據庫中是否有未決消息,並嘗試將它們發送到GCM服務器。如果GCM發現錯誤提示您應該稍後重試,則使用下次發送嘗試的時間戳(並根據指數退避要求設置時間戳)更新數據庫中的消息。如果您從GCM獲得成功回覆,則可以從數據庫中刪除該消息。

+0

謝謝@Eran。但是,使用週期性喚醒系統並不能使我的系統接近即時消息應用程序所要求的實時性。 – GVillani82

+0

@ Joseph82定期喚醒不一定需要很長時間。它可以每秒喚醒以檢查是否有任何未決消息發送到GCM服務器。如果您想減少延遲,可以在Web服務中執行第一次傳遞嘗試,以從客戶端獲取消息,並且僅在單獨的線程中執行重試(如有必要)。我認爲這個解決方案不夠優雅,但它仍然有效。 – Eran

+0

當然@Eran,但安排工作頻率很高我認爲這不是一個好主意。 「SQL代理作業調度程序本身非常輕便,SQL Server本地支持的最小時間間隔爲1分鐘,如果您的目標是儘快讓作業響應新文件,請將計劃設置爲每1分鐘運行一次。」 – GVillani82