处理 Telnet 协商

Question

我正在尝试使用 C++ 和 QT 作为 GUI 来实现 Telnet 客户端。 我不知道如何处理 telnet 协商。 每个 telnet 命令前面都有 IAC，例如

IAC 将不支持_GO_AHEAD

以下是我处理谈判的方式。

1. 在接收的缓冲区中搜索 IAC 字符
2. 根据命令和选项，响应请求

我的问题描述如下：

1. 在发送协商命令后，telnet 服务器似乎不会等待客户端响应。 例如（发送两个或多个命令而不等待客户端响应）

   IAC 将不支持_GO_AHEAD

   IAC 会回声

我应该如何处理这种情况？处理两个请求还是只处理最后一个？

1. 如果我不响应请求，选项值是什么？它们是否设置为默认值？
2. 为什么 IAC 字符 (255) 不会被视为数据而不是命令？

Answer 1

1. 是的，可以针对不同的选项发送多个协商，而无需在每个协商后同步等待响应。

   实际上，即使没有收到回复，每一方都尝试继续（如果您确实决定等待响应，可能会在超时后），因为根据RFC 存在合法情况当不应该或不应该有回复，而且对方可能会出于任何原因忽略该请求，而您无法控制。

   您需要考虑服务器发送的两个协商请求，因为它们都是有效请求（当然，您可以选择拒绝一个或两个）。

   我建议您在注意到它们后立即处理它们（无论“处理”在您的情况下是什么意思），以免在决定等待您的回复时服务器卡住。

   Daniel J. Bernstein 在RFC 1143 中提出了一种可能的方法。它使用有限状态机 (FSM)，并且对协商循环非常稳健。

2. 兼容的服务器（兼容的客户端也是如此）在开始时默认所有可协商选项为 WON'T 和 DON'T（即禁用）连接并且在 WILL 或 DO 确认对 DO 或 WILL 的请求之前不会认为它们已启用分别回复。

   当然，并非所有服务器（或与此相关的客户端）都能正常运行，但您无法预料到对等方可能出现的所有行为异常，因此只需假设所有选项都已禁用，直到请求启用它们和 回复是肯定的。

3. 我在这里假设您实际上要问的是如何服务器将 255 字节作为数据发送给您，而您不会将其误解为 IAC 控制序列（反之亦然，如何将 255 字节作为数据发送到服务器，而不会将其误解为 telnet 命令）。

   答案很简单，服务器（以及相反方向的客户端）发送 IAC 后跟另一个字节 255，而不是单个字节 255，因此实际上将所有值加倍255 是数据流的一部分。

   通过网络接收到后跟 255 的 IAC 后，您的客户端（以及相反方向的服务器）必须在它返回的数据流中将其替换为 255 的单个数据字节。

   RFC 854 也对此进行了介绍。