Azure移動服務與設備作爲服務器的網絡套接字

Question

我記得Windows 8應用程序將充當服務器，接收來自不同客戶端（其他Windows 8應用程序或Excel Web應用程序）的消息的場景。這些消息需要達到較低的延遲（大多數情況下爲<）。 我正在考慮許多不同的解決方案。我肯定會需要某種服務器骨幹來完成匹配（將消息路由到適當的設備）。我試圖在

之間做出決定

1. Azure移動服務。源將向Azure發送郵件，並且Azure會將它們作爲推送通知發送到適當的「服務器」設備 。問題是這裏的延遲不是很好。

2. Azure的移動服務（或簡單的東西像一個簡單的Web API網站）只針對婚介： 實際的消息發送被有網絡套接字連接到服務器應用程序的每個客戶端 建立。這裏我們有非常低的延遲，但我擔心連接問題。從數據保護 的角度來看， 服務器不會存儲任何消息的事實會更好，但會使服務器應用程序在後臺的災難恢復和處理時刻稍微困難一些。

3. Azure服務總線。它應該是這樣做的（服務器 訂閱客戶端消息的訂閱源），但我認爲需要爲每個服務器創建一個新的隊列 （然後客戶端將不得不 瞭解該隊列的名稱，所以像在選項 2一些對接會將是必要的）

你會怎麼推薦？

在此先感謝！

Answer 1

我一直在開發類似的東西，我建議你使用Windows Azure Mobile解決方案來構建這個解決方案，特別是它現在支持Node JS NPM。

http://weblogs.asp.net/scottgu/archive/2013/06/14/windows-azure-major-updates-for-mobile-backend-development.aspx

對於客戶我也建議你使用SignalR這是專爲這種情況下你在那裏實時應用需要從服務器端有很多交易的建造。

http://www.asp.net/signalr

你也可以找到關於如何可以在下面的鏈接二者的整合更多的細節：http://hhaggan.wordpress.com/2013/07/12/signalr-node-js/

我希望這些幫助你，讓我知道你需要什麼。

Answer 2

經過一番思考，讀你的答覆（和MSDN論壇一些人），並分析我的情況下，查詢模式和技術，我更舒服，我決定在以下方面：

一個統一的Web SQL Azure上的Api模型（它甚至可以在一種情況下返回OData IQueryable）將處理消息發送和匹配。

轉發到Windows 8集線器應用程序的消息將通過SignalR和Web套接字完成。這兩個鏈接告訴我如何處理應用程序進入後臺（http://msdn.microsoft.com/nl-be/windows/apps/jj662740.aspx）或失去連接（http://msdn.microsoft.com/nl-be/windows/apps/jj710180） - 仍然希望支持一些丟失連接的分鐘，在此期間服務器將累積消息併發送所有未連接的消息（經過一段時間之後，匹配將被視爲結束並且數據庫將被清理 - 我不確定是否可以通過編程方式或在工作線程上使用工作流來處理此問題，此時看起來似乎足夠簡單，以編程方式處理） 。

萬一我需要婚介期間推送通知，我可以在網頁API實現它們（它需要比在移動服務幾個工作）：http://www.codeproject.com/Articles/506733/Windows-8-Notifications-Push-Notifications-via-Win

所以它更像解決方案2.我會繼續如果我遇到任何複雜情況，你發佈。我最初可能需要更多代碼才能通過移動服務進行設置，但我認爲一旦我按照基本教程設置基本知識，就能夠以更無縫的方式擴展該解決方案。我甚至可能會嘗試使用Entity Framework 6，以實現全異步並最大限度地降低node.js上的吞吐量（但我不希望有任何嚴重的負載）。