在网络编程中遇到的问题

一、问题描述

客户端在连接上服务端,发送数据后,连接断开了,然后又重连。每次连接上发完数据就会断开。

二、问题分析

判断谁主动断开

要判断是哪一边主动断开连接,只有抓包了,使用的是wireshark,下图是抓包的信息:

抓包图

可以看出绿色的是三次握手,服务端IP为106.xxx.xxx.xxx,红色圈起来的部分可以看出是服务端主动断开了连接。

关于三次握手和四次挥手的描述可以查看这篇文章 图解TCP协议中的三次握手和四次挥手

代码查找问题

通过查看日志和代码分析,发现是recv()函数返回值的判断错误,recv()函数返回 -1 ,然后服务端就主动关闭了连接。

// 日志
2018-04-02 16:05:57:566 - [DEBUG] - [game_server_c::recvMsg] Index: 0  nFdId: 21  recv msg nLen = -1
2018-04-02 16:05:57:566 - [INFO] - [game_server_c::recvMsg] recv msg nLen is zero   nFdId: 21  MSG_LEN: -1  MAX_MSG_R: 10240  HEAD_INDEX 202  TAIL_INDEX: 157

三、解决问题

代码中TCP连接使用的是非阻塞的,里面使用了EPOLL 的ET触发,所以可能存在recv的时候没有可用的数据 此时返回的是 -1,errnoEINTR , 所以在接收数据返回小于0 的时候要做判断

recv函数仅仅是copy数据,真正的接收数据是协议来完成的), recv函数返回其实际copy的字节数
如果recv在copy时出错,那么它返回SOCKET_ERROR;
如果recv函数在等待协议接收数据时网络中断了,那么它返回0。
默认 socket 是阻塞的 解阻塞与非阻塞recv返回值没有区分,都是 <0 出错 =0 连接关闭 >0 接收到数据大小,
特别:
返回值<0时并且(errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)的情况下认为连接是正常的,继续接收。
只是阻塞模式下recv会阻塞着接收数据,非阻塞模式下如果没有数据会返回,不会阻塞着读,因此需要循环读取)。
返回说明:
成功执行时,返回接收到的字节数。
另一端已关闭则返回0。
失败返回-1,

errno被设为以下的某个值
EAGAIN:套接字已标记为非阻塞,而接收操作被阻塞或者接收超时
EBADF:sock不是有效的描述词
ECONNREFUSE:远程主机阻绝网络连接
EFAULT:内存空间访问出错
EINTR:操作被信号中断
EINVAL:参数无效
ENOMEM:内存不足
ENOTCONN:与面向连接关联的套接字尚未被连接上
ENOTSOCK:sock索引的不是套接字 当返回值是0时,为正常关闭连接;

所以在recv()函数返回 -1 的时候加上判断


if (0 == nLen)   // 玩家主动关闭
{

 LOG4CPLUS_INFO(g_oServerLogger, "[game_server_c::recvMsg] recv msg nLen is zero "
            << "  nFdId: " << sMsgInfo.nFdId
            << "  MSG_LEN: " << nLen
            << "  MAX_MSG_R: " << MAX_MSG_R
            << "  HEAD_INDEX " << m_pFdArr[nFdIndex].unFdRhead
            << "  TAIL_INDEX: " << m_pFdArr[nFdIndex].unFdTtail);
 closeSocket(sMsgInfo.nFdId, 1);
}
else if (-1 == nLen)
{
    if ((errno != EINTR) && (errno != EWOULDBLOCK) &&( errno != EAGAIN))      
    {
        closeSocket(sMsgInfo.nFdId, 9);
    }
}

四、参考资料

recv函数返回值说明
三次握手、四次握手内容整理
图解TCP协议中的三次握手和四次挥手

你可能感兴趣的:(在网络编程中遇到的问题)