==========TCP 编程的相关问题==========

[FreeWong]

对方通过单片机使用 TCP 客户端的形式(短连接)与我写的服务端进行通讯
他们设计的协议是基于文本的，类似以下格式

@Start:A01:25.41,A02:36.1#

其中#号表示一条完整的可解析的数据的结尾,同时 TCP 客户端要求当服务器收到一条完整的数据后，要回复 @Received 用于表示接收到这条数据。
并且客户端会等待我的这个回复，才会断开 TCP 客户端一侧的连接,十几秒都没有收到则主动断开。(我们不考虑它主动断开的情况)
如果服务端没有回复，则到下一个通讯时间节点时，再次将前面没有收到回复的数据补发，然后再接着发送当前时间节点应该发送的。
像这样
@Start:A01:25.41,A02:36.1#@Start:A01:26.18,A02:38.2#

很多编程语言提供类似 ReadTo() 方法，意思是这个方法不返回，一直读到指定的字符时返回，所以 ReadTo("#") 就会返回一条完整的数据。 但是由于存在补发数据的情况，所以得循环调用这个方法像这样
for{
string 完整的数据 =ReadTo("#")
开始处理完整的数据的函数(完整的数据)
}

你们发现没有，由于我根本不知道客户端会有多少个完整的数据的指示符，所以我的服务端必须要循环调用 ReadTo("#") 并且我根本不知道什么时候该退出循环。
也就无法向 TCP 客户端发送 @Received 让来客户端断开连接。
现在就变成了，我根本不知道何时结束循环也就无法发送 @Received,而客户端也在等待我给它指示断开的指令，这样面临一个类似“死锁”状态。

这里只讨论 ReadTo("#") 这个方法

所以我的看法就，TCP 客户端应该将多条补发数据的格式修改为

@Start:A01:25.41,A02:36.1;@Start:A01:26.18,A02:38.2#

将中间的 #号修改为 ; 号,这样的话， 我都不需要使用循环来读。
请问，我的想法有没有考虑不周全的地方？感谢大家指正。

[ksc010]

太长了，没细看
一般直接用 tcp 协议通讯的话，都设置自定义消息包格式
消息头+消息体
消息头长度固定，头里面包含消息体的长度，这样就知道读取多少位数据停止了

[rrfeng]

不要 ReadTo ，每次用 ReadAll 全读出来，然后另外拆分处理？

[bfdh]

如果对端支持 udp 的话，换 udp 吧，感觉 udp 这种协议设计。使用 tcp 确实存在你说的问题。
如果非得用 tcp ，又不愿意改协议，那就你的接收端加超时，一定时间内没有新的数据达到，就认为是一条消息结束。

[bfdh]

@bfdh #3 更正一下 感觉 udp 这种协议设计 ==> 感觉 udp 更适合这种协议设计

[ysc3839]

这个设计是有问题，看起来 Received 的作用只是控制是否补发，那客户端发完后就应该直接 shutdown ( https://man7.org/linux/man-pages/man2/shutdown.2.html )，这样服务端就能知道数据已经发完了，这个方案甚至不需要修改数据包格式。

[ysc3839]

@rrfeng 这里的问题是客户端发完数据后不会 shutdown ，ReadAll 要等客户端 shutdown 后才会返回。

[momocraft]

想办法避免无限阻塞的 API

[ipwx]

解决方案：

1 、每个客户端给一个 shutdownRequested 变量。
2 、自己开缓冲区处理 ReadTo('#') 的逻辑，用异步 read 。
3 、read 读不到就返回，那么进入 epoll 等待队列。
4 、如果 shutdownRequested ，就唤醒这个 fd 去处理。。

总结：

需要一个完整的 event loop 。但是有了就很容易做

[FreeWong]

@rrfeng 实际编程语言没有 ReadAll ， 如果你的意思是 总是从缓冲区去读，每次读一批，然后接收缓冲区就有了位置，对端才可以继续发送数据过来。但是你如何判断你接收完了? 像这样

声明 512 长度的字节数组
for{
得到的数据= 读到 512 长度的字节数组（）
如果( 得到的数据以用 # 号结尾则是一个完成的数据 )
}

但这是有问题的，如果你正好读的最后一个字符是两条数据中间的 # ，你会认为所有的数据都接收完了 ，实际上还有余下的一个完整的没有被接收下来, 如果你认为读到一个 # 不是所有数据都接收完了，那何时能判断哪个 # 号才表示接收完成？

[FreeWong]

@ksc010 TCP 客户端的实现是对方协议制定好的，我无法修改它，只是用技术角度来分析这个协议的缺陷

[FreeWong]

@bfdh 超时是个办法，但不是一个好办法，我可以定义 5 秒钟都收完，如果收不完，也就结束 了，但这种方式真的不好

[FreeWong]

@ysc3839 TCP 客户端不会主动断开的，它一定要待我回 @Received ，所以这就是我说的 “死锁” 双方都在等，我在等待判断如何才能全部收完，即循环结束 ，对方在等待我回复 @Received

[FreeWong]

@ipwx 这是一个很常见的网络编程问题，应该不会需要这么复杂去解决。。我只是认定对方协议有瑕疵

[ysc3839]

客户端改不了的情况下有一个可能可行的方案，就是服务端一收到数据就立即发送 Received ，然后 read all 直到断开连接，这个方案可行的前提是客户端会把所有数据发完再断开连接。假设客户端是发送数据、接收数据、断开连接顺序执行的话，这个方案是可行的。

[FreeWong]

@ysc3839 看看我的提问的倒数第四行，看看这个办法是否可行

[ipwx]

@FreeWong 不这就是很常见的解决方案。

只不过在比如 python 语言里面你可以用协程 asyncio ，在 node.js 里面可以用回调，把上面的逻辑实现是个很简单的事情。在 C++ 里面你就不得不用多线程或者 event loop 了。

[ysc3839]

@FreeWong 所以你到底能不能改客户端？能改的话那个方法是可行的。本质是用 # 代替 shutdown 来表示“数据已发完”。

[FreeWong]

@ipwx 有兴趣的也愿意的话，用 nodejs 写一个看看。。。

[FreeWong]

@ysc3839 单片机是由供应商提供的，如果方法可行可以让供应商下个版本修改

[ysc3839]

@FreeWong 那建议使用 shutdown 的方式，服务端读到连接关闭即可。

[Sricecake]

问题点在于 TCP 是流式的，你却把它当 HTTP 用。
正常应该是每条数据应该有个 ID 你收到一个# 就回一条 Received(ID)
你只负责一直循环 ReadTo 处理完一条就回一条 Received
客户端判断所有消息都 Received 了再断开连接就行。

[FreeWong]

@Sricecake 客户端的现在的错误逻辑，就是我只要回一条接收到的消息， 它就断开了。。如果客户端自己还有很多数据要发，它照样断 。。。这本来就是在一个错误的逻辑上修补。
客户端是硬件厂商做的，我无法修改

[Sricecake]

按 #19 的说法 方法可行的话让供应商下个版本修改，按正确逻辑改了就可以了吧。

[FreeWong]

我的问题是，我的方法是否可行，有没有逻辑上说不通的地方。。