telnet - 处理 Telnet 协商

Question

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

IAC WILL SUPPRESS_GO_AHEAD

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

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

我的问题描述如下:

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

   IAC WILL SUPPRESS_GO_AHEAD

   IAC WILL ECHO

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

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

Answer 1

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

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

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

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

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

2. 合规服务器(合规客户端也是如此)在连接开始，并且在 DO 或 WILL 请求被 WILL 或 DO< 确认之前，不认为它们已启用/strong>分别回复。

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

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

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

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

   这也包含在 RFC 854 中.