與紅寶石實時通信

我即將用紅寶石編寫遊戲服務器。遊戲的一個特點包括玩家走動&其他人應該能夠看到它。與紅寶石實時通信

我已經使用事件機器編寫了一個純套接字演示。但由於大多數通信都是基於http的，所以我正在尋找一些http輪詢解決方案。當然，我可以使用事件機器來編寫它，但是有沒有這種工作的寶石？

我試過類似faye的東西，但其中大部分都是針對郵件系統的，比如訂閱&發佈到頻道，我似乎無法控制我應該推送哪些客戶端。在我的情況下，我需要能夠推送給特定的客戶，就像一個人從10,10移動到20,20，只有他周圍的人（可能從0到30,30，但不是40,50,50 ）需要收到消息。

------------帶有抽筋的傷口

這是一個快速更新。我正在使用5000個連接進行抽筋，每秒100個客戶端移動，CPU使用率幾乎達到100％。當我將兩個數字都加倍時，CPU使用率仍然是100％左右，並且響應非常緩慢。

很明顯，我沒有使用我擁有的每個資源，而只有一個CPU內核被佔用。需要更多的工作。

------------的Node.js的轉

@ aam1r 其實Node.js的是做的比抽筋更好。通過5000個連接和100個客戶端移動，Cpu使用率超過60％。當我每秒鐘移動10000個連接和200個客戶端時，CPU使用率爲100％，響應速度變慢。同樣的問題在這裏，無論是cramp還是Node.js，每個進程只能使用一個cpu核心。這是一個問題。

------------ JRuby呢？

由於GIL的存在，Ruby MRI沒有真正的多線程同時執行。沒有任何Node.js，所以我要給JRuby一個嘗試。

當客戶端移動時，使用另一個線程來查找所有其他客戶端需要通知（這是一個CPU繁重的工作）。然後將結果推送到頻道。
主線程只是訂閱頻道。當它得到結果時，將它們推送給客戶端。

雖然需要一些時間來編寫演示。

來源

2012-11-10 Dean Winchester

我會建議不要使用輪詢。輪詢會導致太多開銷，因爲每次發出新請求時都會建立新連接。此外，它不會實時足夠你（即你會每隔X秒輪詢 - 不是即刻）

相反，我會建議使用像Cramp之類的東西。來自他們的網站：

Cramp是一個完全異步的實時Web應用框架，在 Ruby中。它建立在EventMachine之上，主要爲而設計，可與更多數量的開放連接和提供全雙工雙向通信。

所有的客戶端都會保持一個持續連接，通過這個連接他們可以發送/接收消息。由於客戶端不會每隔X秒檢查一次，所以不會每次都建立新的連接並且實時發送消息。

你也可以用Node.js代替Cramp。這是一個可用於開發實時應用程序的Javascript框架。

這裏有一些更多的資源，應該幫助你：

來源

2012-11-10 15:39:35

抽筋看起來promising.I'll嘗試一下later.As對Node.js的，我讀到一篇文章，比較它和事件的機器的性能，這是太可怕了。我不確定這是否糟糕。你有沒有使用Node.js性能的經驗？ –

@DeanWinchester：我玩過Node.js框架，但從未構建過需要我擔心性能的問題。我會搜索實際使用Node for online多人遊戲的人發佈的基準和/或結果。 –

我應該自己寫一個demo，也許明天吧。我會保持你的發佈。 –

我會建議使用Espresso與服務器發送的事件。

在服務器端定義流的動作：

class App < E 
    map :/ 

    attr_reader :connections 

    def subscribe 
    @connections ||= [] 
    stream :keep_open do |conn| 
     connections << conn 
     conn.callback { connections.delete conn } 
    end 
    end 

    private 
    def communicate_to_clients 
    connections.each do |conn| 
     conn << 'some message' 
    end 
end

的：keep_open選項將服務器指示不密切的聯繫。

然後打開使用Javascript的連接：

pool = new EventSource('/subscribe'); 
pool.on_message = function(msg) { 
    // here you receive messages sent by server 
    // via communicate_to_clients method 
}

來源

2012-11-10 18:26:33

哇，我怎麼沒有聽說過濃咖啡？我已經計劃在大部分服務器端使用Sinatra，但espresso看起來是一個很好的選擇。然而，至於實時的東西，如果我錯了，請糾正我，就像其他框架一樣，espresso需要一個單獨的進程來處理每個請求。如果是這樣，假設我有1000名玩家在線，那麼我需要1000個流程，每個玩家都需要一個玩家，我認爲這不會奏效。 –

@DeanWinchester，不知道爲什麼你認爲你需要多個進程。一個Espresso流程可以處理任意數量的請求。在示例中，我展示了一個單獨的Espresso進程，將連接添加到池並在需要時與他們進行通信。 –

哦，那我會錯的。我認爲它就像其他框架，rails或sinatra一樣，使用單個進程來處理每個請求。我會仔細看看它。 –

與紅寶石實時通信

回答

相關問題