我試圖設置「倒置」的PUB/SUB與ZeroMQ。與ZeroMQ倒置的PUB/SUB的問題
意思就是說訂閱（SUB）插座屬於一些長期居住的服務器，做zmq_bind();和發佈（PUB）套接字是一個短暫的客戶端，並且zmq_connect()。
我用一個單一的ipc://插座。
我希望來自發布者的消息能夠到達每個訂閱者。
問題：只有一個訂戶進程接收到消息。如果該流程死亡，則發佈商將陷入zmq_term()。
這種操作模式是否支持zmq？如果是的話，那麼我做錯了什麼？如果不是，那麼如何實現我所需要的？
一些額外的細節小例子（在Lua，但是這不應該的問題）：https://gist.github.com/938429
不能多個套接字綁定到一個ipc://地址（我們正在談論的Unix域套接字這裏IPC：// /tmp/test.ipc ==文件/tmp/test.ipc）。
你可以做的是每個子套接字綁定到不同的IPC：//地址，並讓發佈商一個PUB插座連接到每個地址。 ZeroMQ允許一個套接字綁定/連接到多個地址。
上zmq_term阻塞（）是最有可能做的纏綿親密的問題（即有一條消息，PUB套接字試圖發送）。看看ZMQ_LINGER套接字選項。
不能多個套接字綁定到同一地址的一臺機器上，無論是它的IPC或TCP，SUB/PUB或REQ/REP。這就像網絡套接字的綁定。
將消息發送到許多出版商的所有用戶的方式，就是要實現一個簡單的代理，其結合SUB地址和PUB地址。發佈者連接到SUB套接字發送消息，並且訂閱者連接到相同代理的PUB套接字，而代理只是將從SUB套接字接收的所有消息轉發到PUB套接字。它需要一些性能開銷，但編程起來很容易。
在ZeroMQ 2.0中有一個可執行文件zmq_forwarder只能用於這個目的，在2.1中指的是zmq_device（3）函數。
如果我正確理解這一點，那麼經紀人流程將是單一故障點。有沒有辦法避免這種情況？ – 2011-04-25 16:22:13
我這麼認爲。但是由於所有程序都在一臺計算機上運行（使用ipc：// socket），硬件和網絡故障不會成爲問題。經紀人流程本身可能太簡單而不會失敗。但是，如果涉及到很多節點，我不確定這是否是最好的方法。 – 2011-04-26 23:36:42
即使在一臺機器上也總會有一顆混沌猴子。 （只是在開玩笑:-)） – 2011-04-27 04:45:26
有一個ipc：// transport的'特性'，就是說如果兩個進程綁定到同一個IPC端點，那麼第二個會悄悄地從第一個綁定中竊取綁定。這個'功能'是爲了讓進程在崩潰後輕鬆恢復。
這就是爲什麼只有一個用戶正在收到消息。
由於您只有一個發佈者，爲什麼不綁定發佈者，並將訂閱者連接到該發佈者？即使發佈者來來去去，用戶也會自動重新連接。
是的，每個綁定只是覆蓋文件。本來應該算出來的，對於噪音抱歉。 – 2011-04-23 08:06:30
你不是第一個被這個打擊的人;這與其他交通工具非常不一致，因此並不明顯......關於改變這個問題，已經在名單上進行了討論。 – 2012-11-22 05:12:10