【2025-2-10】tcp通信踩坑记录

TCP通信

客户端和服务器都会维护自己fd，处理完数据后，各自关闭自己的fd。
listen 函数会一直监听，新的连接，如果不想监听了，也需要关闭listen_fd。listen函数还可以设置连接的队列个数，最多能监听的连接个数。

accept函数，每建立一个新连接，就会新返回一个新的fd，这个fd就是和当前客户端的连接，如果和该客户端通信完成后，需要关闭fd。服务器可以接收多个fd，这时候就需要维护各自客户端的fd了。

调试318和315通信，一直遇到一个问题，就是明明318已经，创建完套接字，也connect了，没有报错，还send数据成功了，但是看315的日志打印，发现，每次都是走到accept的打印就没有了，而且还伴随着315设备的连接，远端连接重置：

dbclient: Connection to root@192.168.1.1:22 exited: Error reading: Connection reset by peer 这个错误信息表明在尝试通过 SSH 连接到 192.168.1.1 的端口 22（默认的 SSH 端口）时，连接被远程主机重置了

一直以为是双方通信的问题，尝试了很多种方式，以为是accept阻塞住了，但是明明客户端已经connect成功，并且send了数据，没道理的。还怀疑了其他地方提前accept了listen连接，但是注释代码后依然出现这个现象。

每次出现这种情况都伴随着，远端重连，315的日志打印又有滞后性，而且偶然在315终端看到了重启的打印，这才豁然开朗，原来每次连接成功后，都进入了重启系统的函数。才导致断开连接，将打印重启的位置进行注释后，这种现象果然消失了，accept也正常了。