28/REQREP

28/REQREP

ZeroMQ 请求-回复

本文档详细说明了 ZeroMQ 请求-回复模式的语义，该模式涵盖了 REQ、REP、DEALER 和 ROUTER 套接字类型。本规范旨在指导这些套接字类型的实现，以便用户能够依赖可靠的语义。

前言

版权所有 (c) 2013 iMatix Corporation.

本规范是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证（GNU General Public License）条款重新分发和/或修改它；无论是该许可证的第 3 版，或者（由您选择）任何后续版本。发布本规范是希望它有用，但没有任何担保；甚至不包含适销性或特定用途适用性的默示担保。详情请参阅 GNU 通用公共许可证。您应该已经随本程序收到了 GNU 通用公共许可证的副本；如果没有，请访问 https://gnu.ac.cn/licenses。

本规范是一个自由开放标准，并受数字标准组织（Digital Standards Organization）的共识导向规范系统管辖。

本文档中的关键词“MUST”（必须）、“MUST NOT”（禁止）、“REQUIRED”（要求）、“SHALL”（应）、“SHALL NOT”（不应）、“SHOULD”（建议）、“SHOULD NOT”（不建议）、“RECOMMENDED”（推荐）、“MAY”（可以）和“OPTIONAL”（可选）应按RFC 2119中的描述进行解释。

目标

本规范旨在正式记录 REQ、REP、DEALER 和 ROUTER 套接字类型的名称和预期行为，它们共同构成了 ZeroMQ 请求-回复模式。这些套接字的符合性实现 SHOULD（建议）遵守本规范，从而确保应用程序能够依赖可预测的行为。本规范不特定于传输层，但并非所有行为都能在所有传输层上重现。

此模式的总体目标

请求-回复模式适用于各种服务导向架构。它有两种基本形式：同步（REQ 和 REP）和异步（DEALER 和 ROUTER），可以以各种方式混合使用。DEALER 和 ROUTER 套接字是许多更高级协议的构建块，例如 rfc.zeromq.org/spec:18/MDP。

REQ 套接字类型

REQ 套接字类型充当一组匿名服务的客户端，使用锁定步进轮询算法发送请求和接收回复。它专为简单的请求-回复模型设计，其中对故障对等方的可靠性不是问题。

一般行为

  • MAY（可以）连接到任意数量的 REP 或 ROUTER 对等方。
  • SHALL（应）每次只发送一条消息，然后接收一条消息。

请求和回复消息 SHALL（应）在线路上具有以下格式

  • 一个分隔符，包含一个由 REQ 套接字添加的空帧。
  • 一个或多个数据帧，构成应用程序可见的消息。

处理出站消息

  • SHALL（应）在出站消息前加上一个空的定界帧。
  • SHALL（应）使用轮询策略将出站消息路由到已连接的对等方。
  • 当没有已连接的对等方时，SHALL（应）在发送时阻塞，或返回适当的错误。
  • SHALL NOT（不应）丢弃无法发送给已连接对等方的消息。

处理入站消息

  • SHALL（应）只接受来自其上次发送请求的对等方的入站消息。
  • SHALL（应）静默丢弃从其他对等方收到的任何消息。

REP 套接字类型

REP 套接字类型充当一组客户端对等方的服务，接收请求并将回复发送回请求对等方。它专为简单的远程过程调用模型设计。

一般行为

  • MAY（可以）连接到任意数量的 REQ 或 DEALER 对等方。
  • SHALL NOT（不应）以任何方式过滤或修改出站或入站消息。
  • SHALL（应）每次只接收一条消息，然后发送一条消息。

请求和回复消息 SHALL（应）在线路上具有以下格式

  • 一个地址信封，包含零个或多个帧，每个帧包含一个身份。
  • 一个分隔符，包含一个空帧。
  • 一个或多个数据帧，构成应用程序可见的消息。

处理入站消息

  • SHALL（应）使用公平排队策略从其对等方接收入站消息。
  • SHALL（应）移除并存储地址信封，包括分隔符。
  • SHALL（应）将剩余的数据帧传递给其调用应用程序。

处理出站消息

  • SHALL（应）等待其调用应用程序的单个回复消息。
  • SHALL（应）预置地址信封和分隔符。
  • SHALL（应）将此消息发送回原始对等方。
  • 如果原始对等方不再连接，SHALL（应）静默丢弃回复，或返回错误。
  • SHALL NOT（不应）在发送时阻塞。

DEALER 套接字类型

DEALER 套接字类型与一组匿名对等方通信，使用轮询算法发送和接收消息。它是可靠的，因为它不丢弃消息。DEALER 作为 REQ 的异步替代品，用于与 REP 或 ROUTER 服务器通信的客户端。它也用于请求-回复代理。

一般行为

  • MAY（可以）连接到任意数量的 REP 或 ROUTER 对等方，并且 MAY（可以）同时发送和接收消息。
  • SHALL NOT（不应）以任何方式过滤或修改出站或入站消息。
  • SHALL（应）为每个已连接的对等方维护一个双向队列，允许出站和入站消息独立排队。
  • 在发起与对等方的出站连接时，SHALL（应）创建一个双向队列，并且 SHALL（应）无论连接是否建立都维护该双向队列。
  • 当对等方连接到它时，SHALL（应）创建一个双向队列。如果该对等方断开连接，DEALER 套接字 SHALL（应）销毁其双向队列，并且 SHALL（应）丢弃其中包含的任何消息。
  • SHOULD（建议）将入站和出站队列大小限制在一个运行时可配置的限制内。

处理出站消息

  • SHALL（应）仅当对等方的出站队列未满时，才将其视为可用。
  • SHALL（应）使用轮询策略将出站消息路由到可用对等方。
  • 当没有可用对等方时，SHALL（应）在发送时阻塞，或返回适当的错误。
  • 当没有可用对等方时，SHALL NOT（不应）接受更多消息。
  • SHALL NOT（不应）丢弃无法排队的消息。

处理入站消息

  • SHALL（应）使用公平排队策略从其对等方接收入站消息。
  • SHALL（应）将这些消息发送到其调用应用程序。

ROUTER 套接字类型

ROUTER 套接字类型与一组对等方通信，使用显式寻址，以便将每条出站消息发送到特定的对等方连接。ROUTER 作为 REP 的异步替代品，常被用作与 DEALER 客户端通信的服务器的基础。

一般行为

  • MAY（可以）连接到任意数量的 REQ、DEALER 或 ROUTER 对等方，并且 MAY（可以）同时发送和接收消息。
  • SHALL（应）为每个已连接的对等方维护一个双向队列，允许出站和入站消息独立排队。
  • 在发起与对等方的出站连接时，SHALL（应）创建一个双向队列，并且 SHALL（应）无论连接是否建立都维护该双向队列。
  • 当对等方连接到它时，SHALL（应）创建一个双向队列。如果该对等方断开连接，ROUTER 套接字 SHALL（应）销毁其双向队列，并且 SHALL（应）丢弃其中包含的任何消息。
  • SHALL（应）使用唯一的“身份”二进制字符串标识每个双向队列。
  • SHOULD（建议）允许对等方通过 Identity 元数据属性显式指定其身份。
  • SHOULD（建议）将入站和出站队列大小限制在一个运行时可配置的限制内。

处理入站消息

  • SHALL（应）使用公平排队策略从其对等方接收入站消息。
  • SHALL（应）在每个入站消息前加上一个包含原始双向队列身份的帧。
  • SHALL（应）将生成的消息发送到其调用应用程序。

处理出站消息

  • SHALL（应）从每条出站消息中移除第一个帧，并将其用作双向队列的身份。
  • 如果出站队列存在且有空间，SHALL（应）将消息路由到该出站队列。
  • 如果队列不存在或已满，SHALL（应）根据配置选择静默丢弃消息或返回错误。
  • SHALL NOT（不应）在发送时阻塞。

安全方面

本规范不涉及安全方面。