一对一的场景

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

1. 消息的帧格式是怎样的？有空帧么？