处理tcp里的粘包问题

typedef struct _CONN_BUFFER
{
    uint8_t  buffer[CONN_BUFFER_LENGTH];
    uint32_t tail;
    uint64_t id;
    time_t access_time;
    uint32_t ip;
    int readerId;
    uint8_t used;
}CONN_BUFFER;

CONN_BUFFER g_ConnBuffer[MAX_CONN_COUNT];

所有的socketfd都放入g_ConnBuffer中，其中used标志其可用状态，read此fd前要检查之。

tail指向数据尾部，当处理完一个数据包，将包的最后位置到tail的数据拷贝到前面；与下次收到的包组合。这样就处理了粘包问题；

CONN_BUFFER_LENGTH当前定义了1024字节，如果Client发送速率太快，导致buffer满，则会从epoll事件中移除，并关闭fd；

时间： 2024-11-07 03:01:49

处理tcp里的粘包问题的相关文章

有关TCP和UDP 粘包消息保护边界

http://www.cnblogs.com/lancidie/archive/2013/10/28/3392428.html 在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因此TCP的socket编程,收发两端(客户端和服务器端)都要有一一成对的 socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包.这样,接收端,就难于分辨出来了,必须提供科学的拆包机

Netty系列（四）TCP拆包和粘包

Netty系列(四)TCP拆包和粘包一.拆包和粘包问题 (1) 一个小的Socket Buffer问题在基于流的传输里比如 TCP/IP,接收到的数据会先被存储到一个 socket 接收缓冲里.不幸的是,基于流的传输并不是一个数据包队列,而是一个字节队列.即使你发送了 2 个独立的数据包,操作系统也不会作为 2 个消息处理而仅仅是作为一连串的字节而言.因此这是不能保证你远程写入的数据就会准确地读取.举个例子,让我们假设操作系统的 TCP/TP 协议栈已经接收了 3 个数据包: 由于基于流传输

TCP 拆、粘包

Netty(三) 什么是 TCP 拆.粘包?如何解决? 前言记得前段时间我们生产上的一个网关出现了故障. 这个网关逻辑非常简单,就是接收客户端的请求然后解析报文最后发送短信. 但这个请求并不是常见的 HTTP ,而是利用 Netty 自定义的协议. 有个前提是:网关是需要读取一段完整的报文才能进行后面的逻辑. 问题是有天突然发现网关解析报文出错,查看了客户端的发送日志也没发现问题,最后通过日志发现收到了许多不完整的报文,有些还多了. 于是想会不会是 TCP 拆.粘包带来的问题,最后利用 Net

TCP网络传输“粘包”问题，经典解决（附代码）

一.前言关于TCP网络传输粘包,网上很多人写了原理.总结起来就一句话:这里拿Server和Client长连接,Server和Client之间通过信令传输做说明: Server发送的时候按照一条条信令发送,到达操作系统网络层,首先进入缓冲池,然后TCP协议层从池子中获取数据,传输给Client.我们知道TCP的传输有几个方案,比如,滑动窗口.1比特方案.所以Client收到的数据已经不可能是一个个完整的信令的. 个人理解TCP粘包的概念:它描述了一个场景:"信令是一个个紧挨着的,好像是被粘在一起

关于TCP封包、粘包、半包

关于Tcp封包很多朋友已经对此作了不少研究,也花费不少心血编写了实现代码和blog文档.当然也充斥着一些各式的评论,自己看了一下,总结一些心得. 首先我们学习一下这些朋友的心得,他们是: http://blog.csdn.net/stamhe/article/details/4569530 http://www.cppblog.com/tx7do/archive/2011/05/04/145699.html //……………… 当然还有太多,很多东西粘来粘区也不知道到底是谁的原作,J 看这些朋友

python学习_day30_基于tcp协议的粘包现象

1.基于远程执行命令的程序需用到subprocess模块服务端: #1.执行客户端发送的指令 import socket import subprocess phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM) phone.bind(('127.0.0.1',8090)) phone.listen(5) while True: conn,addr=phone.accept() print('IP:%s PORT:%s' %(addr[0

tcp协议下粘包问题的产生及解决方案

1.粘包产生原因: (1)TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一个TCP段.若连续几次需要send的数据都很少,通常TCP会根据优化算法(Nagle)把这些数据合成一个TCP段后一次发送出去,这样接收方就收到了粘包数据: (2)接收方不知道消息之间的界限,不知道一次性提取多少字节的数据:接收时有字节的限制,如果超过这个限制没有接收完的会留在操作系统缓存,下次再执行命令获取结果时,优先收取上次命令结果残留的信息: 注:UDP是无连接的,面向消息的,提供高效率服务.不会使用

基于tcp协议下粘包现象和解决方案

一.缓冲区每个 socket 被创建后,都会分配两个缓冲区,输入缓冲区和输出缓冲区.write()/send() 并不立即向网络中传输数据,而是先将数据写入缓冲区中,再由TCP协议将数据从缓冲区发送到目标机器.一旦将数据写入到缓冲区,函数就可以成功返回,不管它们有没有到达目标机器,也不管它们何时被发送到网络,这些都是TCP协议负责的事情.TCP协议独立于 write()/send() 函数,数据有可能刚被写入缓冲区就发送到网络,也可能在缓冲区中不断积压,多次写入的数据被一次性发送到网络,这取决

tcp协议产生-粘包问题的解决方案

客户端 1 客户端 2 3 from socket import * 4 import json,struct 5 6 7 client=socket(AF_INET,SOCK_STREAM) 8 client.connect(('127.0.0.1',8080)) 9 10 11 while True: 12 cmd=input('>>>').strip() 13 if len(cmd)==0:continue 14 client.send(cmd.encode('utf8')) 15