处理Telnet协商

Question

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

  

IAC将SUPPRESS_GO_AHEAD

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

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

我的问题描述如下：

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

     

   IAC将SUPPRESS_GO_AHEAD

        

   IAC将ECHO

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

1. 如果我不回复请求，选项值会是多少？它们是否设为默认值？
2. 为什么IAC字符（255）不会被视为数据而不是命令？

Answer 1

1. 是的，允许为不同的选项发出几个协商，而不是在每个选项之后同步等待响应。

   实际上，即使没有收到回复，每一方都要继续尝试继续（可能在一段时间后暂停，如果你决定等待回复），因为根据{{3}有合法情况当不应该或不应该是回复时，另一方可能因任何原因而忽略该请求而你无法控制该请求。

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

   我建议您在注意到它们时立即处理它们（无论“处理”意味着什么），以免在服务器等待您的回复时陷入困境。

   Daniel J. Bernstein在RFC中提出了一种可行的方法。它使用有限状态机（FSM），并且在协商循环方面非常强大。

2. 兼容服务器（兼容客户端也是如此）默认所有可协商选项为不会和不（即禁用）在 WILL 或 DO <确认 DO 或 的请求之前，不会考虑启用连接/ strong>分别回复。

   当然，并非所有服务器（或客户端）都能正常运行，但您无法预测对等方可能会出现的所有方式，因此请假设所有选项都被禁用，直到请求启用它们和答复是肯定的。

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

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

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

   RFC 1143。

也涵盖了这一点