基于POSIX套接字的TCP程序：服务端未接收第二个数据包

从你描述的问题来看——客户端调用write时套接字文件描述符变成了0（这是标准输入stdin的fd），但你监控了存储客户端fd的变量没发现被修改，核心矛盾点在于你认为应该使用的fd和实际write调用用的fd不是同一个，下面是一步步的排查方向：

1. 先确认登出逻辑里write的参数是不是真的用错了变量 #

最常见的低级错误就是变量名写错或者作用域覆盖：

• 检查登出函数里的write调用，是不是误写了fd参数？比如本来应该用全局的client变量，结果写成了某个局部变量（比如函数里定义了int client = 0;覆盖了全局变量）。
• 直接在write调用前加一行打印验证：

  printf("Write using fd: %d, expected client fd: %d\n", used_fd, client);
  

  对比这两个值，如果不一样，那就是你调用write时传错了参数，和变量是否被修改无关。

2. 排查客户端fd变量的作用域与生命周期 #

如果client是局部变量（比如在main函数里定义的），而登出逻辑是在另一个函数（比如信号处理函数、atexit注册的退出钩子）里执行的，很可能出现无法正确访问到正确的fd变量的情况：

• 比如如果客户端退出是通过Ctrl+C触发的SIGINT信号，信号处理函数里如果引用的client是局部变量，那这个变量可能已经超出作用域，值变成随机的（刚好是0）。
• 解决思路：把client设为全局变量，或者用静态变量，或者如果用sigaction处理信号，可以通过sa_sigaction的参数传递fd。

3. 检查退出流程的执行顺序 #

有没有可能在发送登出包之前，套接字已经被关闭了？

• 比如有些逻辑会在退出前先执行close(client)，然后再调用登出函数发数据包——这时候fd已经被系统回收，后续用这个fd调用write会返回错误，但如果你的代码没检查write的返回值，可能没发现，而且系统可能把这个fd重新分配为0（虽然概率低，但有可能）。
• 如果登出逻辑是注册在atexit里的，要注意atexit的函数是在exit调用后执行的，这时候有些资源可能已经被提前释放，包括套接字。

4. 用系统调用跟踪工具定位问题 #

如果上面的排查都没结果，直接用strace跟踪客户端的系统调用，能直观看到问题：

• 执行命令：strace ./your_client_executable
• 找到退出时的write调用，看它的第一个参数是不是0，同时可以加上-f参数跟踪线程，找到是哪个函数发起的这个错误的write调用，顺着调用栈就能找到变量误用的地方。

顺便看服务端的潜在问题（虽然核心在客户端） #

你的服务端mainLoop里，每次accept一个客户端后直接调用(*packetHandler)();，这是同步阻塞处理——如果packetHandler是一直阻塞读取客户端数据，那服务端同一时间只能处理一个客户端，后面的连接会排队。不过这和你当前登出包收不到的问题无关，但如果后续要支持多客户端，得改成每个客户端开线程/进程，或者用IO多路复用。

内容的提问来源于stack exchange，提问作者reeeee