Telnet客户及其对EOL的处理
这是一个相当复杂的问题，为此我道歉。 我写了一个Linux C套接字应用程序，一个简单的聊天服务器的基本框架。 服务器正在我的笔记本电脑上运行。 客户端是Telnet，直到我编写指定的客户端应用程序（这将更加安全，希望如此）。 我知道，有更好的应用程序可以从客户端发送通用网络数据，但我对为什么某个东西在一个Telnet客户端而不是另一个客户端上发生感兴趣。
第一个Telnet客户端测试是在另一台Linux笔记本电脑上。 它按预期工作。 然而，下一个是一个名为BBSSH的Blackberry应用程序，允许Telnet和SSH连接。 我通过Telnet选项，它也有效。 除此之外，它并不完全正确。
服务器代码执行通常的read调用以检索数据块，该数据块被视为字符串，即消息。 前客户端读取，直到我按Enter键，然后它发送一个字符串。 然而，BB应用程序会发送每一个字符，就像我在每个字符后按下输入一样，我没有。 显然这与缓冲有关，某些客户端从用户输入中选择EOL等等。我只是无法确定它。
为了说明，这是服务器输出从客户端收到的消息。
首先，来自Linux客户端的消息：
client name: this is a test
现在，对于BBSSH：
client name: t client name: h client name: i client name: s client name: client name: i client name: s client name: client name: a client name: client name: t client name: e client name: s client name: t
有帮助吗？
Telnet客户端可以在线路模式或字符模式下运行。 出于某种原因，BBSSH客户端似乎在字符模式下运行。
您的服务器可能会通过在telnet连接开始时进行的协商期间向客户端发送指令来强制客户端进入线路模式。
您的服务器需要发送到客户端的字节序列是0x255 0x253 0x34，其转换为“解释为命令，执行，线模式”。 如果客户端愿意/能够以行模式操作，它应该回复0x255 0x251 0x34（“解释为命令，将，线路模式”）。
如果这对您来说都是新手（即您的telnet服务器目前根本没有进行任何协商），请谷歌查看“telnet negotiation”等术语或查看一些相关的RFCS（RFC 854是Telnet本身，RFC 1184涵盖Linemode选项）。
TCP是以流为导向的，所以没有“消息”这样的东西。 您可能会一起收到所有数据，或者一次只收到它的一部分。
在您的情况下，您可能希望缓冲收到的任何内容，直到您点击EOL标记。