41/CLIENTSERVER

41/CLIENTSERVER

ZeroMQ 客户端-服务器

本文档规范了 ZeroMQ 客户端-服务器模式的语义，该模式涵盖了 CLIENT 和 SERVER 套接字类型。本规范旨在指导这些套接字类型的实现，以便用户可以依赖可靠的语义。

前言

版权所有 (c) 2015 iMatix Corporation。

本规范是自由软件；你可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；许可证的第三版，或（根据你的选择）任何后续版本。分发本规范是希望它会有用，但**不提供任何保证**；甚至不包括适销性或特定用途适用性的默示保证。详情请参阅 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 中所述进行解释。

目标

本规范旨在正式记录 CLIENT 和 SERVER 套接字类型的名称和预期行为，它们共同构成了 ZeroMQ 客户端-服务器模式。这些套接字的合规实现 SHOULD 遵守本规范，从而确保应用程序可以依赖可预测的行为。本规范不特定于传输协议，但并非所有行为都可以在所有传输协议上重现。

本模式的总体目标

客户端-服务器模式是线程安全套接字新系列的一员。它是路由-分发模式（router-dealer pattern）的线程安全替代方案。客户端-服务器模式适用于各种服务导向架构（service-oriented architectures），并且与路由-分发模式一样，是异步的。它在 CLIENT 和 SERVER 套接字之间提供了异步的双向消息流。所有流程均由 CLIENT 发起。客户端-服务器模式是构建更高级协议的基础。

为了使 API 线程安全，发送和接收消息 MUST 是原子操作，并且一个 API 调用 MUST 完成整个消息的接收或发送。因此，客户端-服务器模式（以及其他线程安全系列）MUST NOT 允许多部分消息（multipart messages）。

此模式旨在弃用并最终取代请求-回复模式（request-reply pattern）。

CLIENT 套接字类型

CLIENT 套接字类型与一个或多个 SERVER 对等端（peer）通信。如果连接到多个对等端，它会以轮询（round-robin）方式将发送的消息分散到这些对等端之间。读取时，它公平地从每个对等端依次读取。在正常情况下不丢失消息，因此它是可靠的。

通用行为

  • MAY 连接到任意数量的 SERVER 对等端，并且 MAY 同时发送和接收消息。
  • SHALL NOT 以任何方式过滤或修改出站或入站消息。
  • SHALL 为每个连接的对等端维护一个双队列（double queue），允许出站和入站消息独立排队。
  • SHALL 在发起与对等端的出站连接时创建一个双队列，并且无论连接是否建立，SHALL 都维护该双队列。
  • SHALL 在对等端连接到它时创建一个双队列。如果此对等端断开连接，CLIENT 套接字 SHALL 销毁其双队列并 SHALL 丢弃其中包含的任何消息。
  • SHOULD 将入站和出站队列大小限制在运行时可配置的上限。
  • MUST 是线程安全的，并允许从多个线程接收和发送。

处理出站消息

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

处理入站消息

  • SHALL 使用公平排队（fair-queuing）策略从其对等端接收入站消息。
  • SHALL 将这些消息传递给调用它的应用程序。
  • MUST 丢弃多部分消息的任何部分。
  • MAY 断开正在发送多部分消息的对等端。

SERVER 套接字类型

SERVER 套接字类型与零个或多个 CLIENT 对等端通信，使用显式的路由 ID（routing-id），以便每条出站消息都被发送到特定的 CLIENT 对等端。

通用行为

  • MAY 连接到任意数量的 CLIENT 对等端，并且 MAY 同时发送和接收消息。
  • SHALL NOT 以任何方式过滤或修改出站或入站消息。
  • SHALL 为每个连接的对等端维护一个双队列（double queue），允许出站和入站消息独立排队。
  • SHALL 在发起与对等端的出站连接时创建一个双队列，并且无论连接是否建立，SHALL 都维护该双队列。
  • SHALL 在对等端连接到它时创建一个双队列。如果此对等端断开连接，SERVER 套接字 SHALL 销毁其双队列并 SHALL 丢弃其中包含的任何消息。
  • SHALL 使用唯一的“路由 ID”（routing id）标识每个双队列，该 ID 是一个非零的 32 位无符号整数值。
  • SHALL NOT 允许对等端显式指定其路由 ID。
  • SHOULD 将入站和出站队列大小限制在运行时可配置的上限。

处理入站消息

  • SHALL 使用公平排队（fair-queuing）策略从其对等端接收入站消息。
  • SHALL 将接收到的消息传递给调用它的应用程序。
  • SHALL 为应用程序提供一个 API 来检索消息的路由 ID。
  • MUST 丢弃多部分消息的任何部分。
  • MAY 断开正在发送多部分消息的对等端。

处理出站消息

  • SHALL 为应用程序提供一个 API 来设置消息的路由 ID。
  • 如果出站队列存在且未满，SHALL 将消息路由到该队列。
  • 如果队列不存在，SHALL 返回错误。
  • 如果队列已满，SHALL 在发送时阻塞，除非另有配置。
  • SHALL NOT 丢弃无法排队的消息。
  • MUST NOT 发送多部分消息（multipart messages）。

安全方面

本规范没有安全方面的内容。