2014-04-15 73 views
0

我在設計一個監視和控制界面,管理許多服務。需要有正面的反饋,所以我想使用REQ/REP通道來獲得每個請求的響應。用C++ 11期貨混合ZeroMQ REQ/REP

但是,我擔心通道的同步特性以及在發送其他請求之前需要等待每個請求完成的事實。我已經讀了一些關於ROUTER/DEALER模式,看起來他們會工作,但它可能會使用一些抽象來隱藏路由細節。

使用C++ 11期貨是否有意義,使得可以提出返回未來的請求?通過這種方式,可以發出一些請求,然後等待在期貨系列上被調用?

未來將封裝將請求與響應關聯所需的詳細信息。

有沒有人混合這些概念?

謝謝。

回答

0

未來將會將您的實現與inproc套接字綁定在一起,因爲您無法實現未來的進程。

要從併發請求中獲得任何好處,您需要多個服務器響應。

你的問題不清楚拓撲結構,你不解釋你是否有多個請求者和一個答覆者,或者一個請求者可以在等待答覆(包括提出更多請求)的同時做其他工作。如果更晚,你需要一種匹配回覆請求的方式,除非你能保證處理順序。

+0

未來將用於管理響應。情景是這樣的:一些工作人員被髮送一個需要回復的請求。每個請求都需要一些時間才能完成。每個請求都是通過一個抽象接口進行的,其中像「calculate(X)= Z」這樣的請求會返回「FutureRep 」。在所有請求完成之後,執行一些類型的「等待所有」。 FutureRep 會將XREP/XREQ中描述的細節作爲ROUTER/DEALER模式的一部分進行封裝,使得響應與請求正確關聯。 – JeffV

+0

讓我們忘記花哨的期貨位,並瞭解您提出的拓撲結構。 –

+0

每個'worker'是一個REQ套接字,而服務器是'REP'套接字。一臺服務器只能對請求進行順序響應,因此爲了並行處理請求,您需要更多的服務器,這意味着中間有一個DEALER/ROUTER代理來分配工作負載。你不需要任何花哨的回覆處理來做到這一點。每個工人都在等待其迴應。在此期間它可以做其他工作,只是在需要響應時輪詢/讀取套接字。 –