的cometd服務與廣播信道

Question

在文章http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html筆者介紹：

常與PubSub的，開發商覺得有必要，以提供私人信息到客戶端爲每個用戶創建一個通道。例如，如果交易系統想要通知用戶完成交易，則誘惑是創建像/ trades/a_user_id這樣的頻道，並且每個用戶將訂閱他們自己的頻道。這種方法很有效，但並不是解決這個問題的最合理的方式，並且需要安全代碼來防止未經授權的客戶訂閱其他用戶的頻道。

爲特定用戶實現消息的服務和廣播頻道之間的權衡是什麼？我理解權衡的安全性方面，但資源開銷又如何？我不明白爲什麼會有更多的資源用於廣播頻道，而不是定製路由服務。如果你能解釋爲什麼一個人在用例上比另一個更好，而不是一個明智或不明智的陳述，那可能會幫助我做出決定。

Answer 1

這篇文章很老了，它指的是CometD 1，而我們現在在CometD 3。 您可能想要檢查CometD website的更新並閱讀CometD 3 documentation。

後面廣播VS服務信道的概念是仍然有效的cometd 3.

用於創建的每個信道，作爲它的廣播或業務信道的服務器分配的數據結構。

在這篇文章的例子中，對比創建N個廣播頻道 - 每個user_id一個，而不是創建一個服務頻道。前者的解決方案顯然是在服務器上使用比後者更多的資源，並且可能會偷看（客戶端可能會猜到user_id並訂閱該頻道，從而接收發往其他用戶的消息）。

對於這種特殊情況，所有應用程序需要做的是將消息傳遞給特定的客戶端。對於這種用例，最好使用服務通道，因爲它使用更少的資源（相同的服務器端通道可以用於所有用戶，而不會有用戶收到不指定給他/她的消息的風險），它是更安全。