一對一的場景
REQ-REP模式是阻塞式的，也就是說必須要client先發(fā)送一條消息給server，然后server才可以返回一個response給client。任何順序上的錯誤都會導(dǎo)致報錯。
服務(wù)端代碼
- 首先是創(chuàng)建一個context
- 之后創(chuàng)建一個新的socket，類型定義為ZMQ_REP,并把這個socket綁定到一個地址
zmq::context_t context (1);
zmq::socket_t socket (context, ZMQ_REP);
socket.bind ("tcp://*:5555");
- 接下來就可以阻塞式的等待client發(fā)送消息
socket.recv (&message);
- 處理完收到的消息后，返回一個response
zmq::message_t reply (5);
socket.send (reply);
客戶端代碼
- 一上來也是創(chuàng)建context和socket，并連接到一個地址
zmq::context_t context (1
zmq::socket_t socket (context, ZMQ_REQ);
socket.connect ("tcp://localhost:5555");
- 然后Client端就可以通過socket來發(fā)送消息
zmq::message_t request (5);
socket.send (request);
- 消息發(fā)送成功后等待reply
zmq::message_t reply;
socket.recv (&reply);
之前演示的是一對一的通信場景，但是實際通信場景下，可能會有多個服務(wù)端或多個客戶端的場景。
多個客戶端對多個服務(wù)端
如下圖演示的是一個一對多的例子，
- client端可以綁定socket（客戶端只有一個socket）到不同服務(wù)端的不同sockets（不同服務(wù)端的socket應(yīng)該綁定了不同的地址）上
- 接下來REQ socket就可以在這些server端分發(fā)請求了，比如說有R1/R2/R3/R4四個請求，R1/R4被發(fā)送到了service A處理。
- 這種場景下添加新的client是方便的，你每添加一個client，只要把這個client和當(dāng)前所有在工作的server的socket連接一下就好
-
但是當(dāng)server的負載不夠，需要增加server的時候，問題就來了，相當(dāng)于每個client端都要更新一下自己連接的socket。
在實際的應(yīng)用場景中，這個系統(tǒng)維護起來顯然不容易。
所以這個時候就引入了brocker
Broker
引入broker后，之前的問題解決了，當(dāng)增加server端時，不需要修改所有的client端，只需要更新一下broker就好了。
這里引入了兩種新的socket類型，DEALER和ROUTER。
Open topics
- 消息的幀格式是怎樣的？有空幀么？
