一对一的场景
REQ-REP模式是阻塞式的，也就是说必须要client先发送一条消息给server，然后server才可以返回一个response给client。任何顺序上的错误都会导致报错。
服务端代码
- 首先是创建一个context
- 之后创建一个新的socket，类型定义为ZMQ_REP,并把这个socket绑定到一个地址
zmq::context_t context (1);
zmq::socket_t socket (context, ZMQ_REP);
socket.bind ("tcp://*:5555");
- 接下来就可以阻塞式的等待client发送消息
socket.recv (&message);
- 处理完收到的消息后，返回一个response
zmq::message_t reply (5);
socket.send (reply);
客户端代码
- 一上来也是创建context和socket，并连接到一个地址
zmq::context_t context (1
zmq::socket_t socket (context, ZMQ_REQ);
socket.connect ("tcp://localhost:5555");
- 然后Client端就可以通过socket来发送消息
zmq::message_t request (5);
socket.send (request);
- 消息发送成功后等待reply
zmq::message_t reply;
socket.recv (&reply);
之前演示的是一对一的通信场景，但是实际通信场景下，可能会有多个服务端或多个客户端的场景。
多个客户端对多个服务端
如下图演示的是一个一对多的例子，
- client端可以绑定socket（客户端只有一个socket）到不同服务端的不同sockets（不同服务端的socket应该绑定了不同的地址）上
- 接下来REQ socket就可以在这些server端分发请求了，比如说有R1/R2/R3/R4四个请求，R1/R4被发送到了service A处理。
- 这种场景下添加新的client是方便的，你每添加一个client，只要把这个client和当前所有在工作的server的socket连接一下就好
-
但是当server的负载不够，需要增加server的时候，问题就来了，相当于每个client端都要更新一下自己连接的socket。
在实际的应用场景中，这个系统维护起来显然不容易。
所以这个时候就引入了brocker
Broker
引入broker后，之前的问题解决了，当增加server端时，不需要修改所有的client端，只需要更新一下broker就好了。
这里引入了两种新的socket类型，DEALER和ROUTER。
Open topics
- 消息的帧格式是怎样的？有空帧么？
