muduo库chat server对TCP粘包问题的处理
来源:互联网 发布:java去除验证码干扰线 编辑:程序博客网 时间:2024/05/19 21:00
粘包问题的最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪。我们通过使用某种方案给出边界,例如:
- 发送定长包。如果每个消息的大小都是一样的,那么在接收对等方只要累计接收数据,直到数据等于一个定长的数值就将它作为一个消息。
- 包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n,则会误判为消息的边界。
- 包头加上包体长度。包头是定长的4个字节,说明了包体的长度。接收对等方先接收包体长度,依据包体长度来接收包体。
- 使用更加复杂的应用层协议。
muduo库采用的是第三种方案,包头存放包体长度。
实现比较简单,直接上代码:
//在该函数中解析消息,是ChatServer首先调用的函数,通过定长包的形式解决了TCP的粘包问题 void onMessage(const muduo::net::TcpConnectionPtr& conn, muduo::net::Buffer* buf, muduo::Timestamp receiveTime) { while (buf->readableBytes() >= kHeaderLen) // kHeaderLen == 4 //判断是否超过包头,如果包头都超不过,那半个消息都算不上 { // FIXME: use Buffer::peekInt32() const void* data = buf->peek(); //偷看一下readable的当前首地址 int32_t be32 = *static_cast<const int32_t*>(data); // SIGBUS //转化成32位 const int32_t len = muduo::net::sockets::networkToHost32(be32); //转换成主机字节序 if (len > 65536 || len < 0) //如果消息超过64K,或者长度小于0,不合法,干掉它。 { LOG_ERROR << "Invalid length " << len; conn->shutdown(); // FIXME: disable reading break; } else if (buf->readableBytes() >= len + kHeaderLen) //如果缓冲区可读的数据是否>=len+head,说明是一条完整的消息,取走 { //len是头部规定的体部长度 buf->retrieve(kHeaderLen); //取头部 muduo::string message(buf->peek(), len); //取包体 messageCallback_(conn, message, receiveTime); //取出包体后就可以处理回调了 buf->retrieve(len); //然后把字节取走 } else //未达到一条完整的消息 { break; } } }
0 0
- muduo库chat server对TCP粘包问题的处理
- muduo库chat server的shared_ptr和TLS实现分析
- 处理tcp粘包问题
- muduo库TcpConnection对send、shutdown、SIGPIPE的处理
- 【muduo网络库学习】之基本的TCP Server工作机制
- TCP的粘包问题
- TCP的粘包问题
- TCP的粘包问题
- TCP的粘包问题
- tcp粘包,断包问题及处理
- TCP粘包处理
- Node(3) TCP-based chat server
- 关于tcp粘包的处理
- tcp粘包的处理(待完成)
- TCP新手误区--粘包的处理
- tcp中的粘包、半包的处理方法
- 关于TCP粘包和半包的处理
- socket中tcp的断包、粘包处理方法
- 数学函数
- 结构体struct前面加 typedef和不加typedef的区别
- UVa1025
- 10035---Spring整合Shiro做权限控制模块详细案例分析
- Unity3D控制动画播放
- muduo库chat server对TCP粘包问题的处理
- Spring4 实战笔记(4):基于Spring构建Web应用
- iOS 修改webView字体大小,设置宽度及缩放效果
- java的各种加载和初始化的详细过程
- JAVA-API解释说明
- OpenGL中一些函数的整理(二)
- android ---notification详解
- usaco3.1.5 Stamps
- Java多线程学习笔记(1)