品牌型网站设计推荐,珠海建网站设计,利用网站宣传腐倡廉建设工作报道,宠物网站页面设计创意国外#xfeff;#xfeff;这两天看csdn有一些关于socket粘包#xff0c;socket缓冲区设置的问题。发现自己不是非常清楚#xff0c;所以查资料了解记录一下#xff1a; 一两个简单概念长连接与短连接#xff1a;1.长连接 Client方与Server方先建立通讯连接。连接建立后不断… 这两天看csdn有一些关于socket粘包socket缓冲区设置的问题。发现自己不是非常清楚所以查资料了解记录一下 一两个简单概念长连接与短连接1.长连接 Client方与Server方先建立通讯连接。连接建立后不断开。 然后再进行报文发送和接收。 2.短连接 Client方与Server每进行一次报文收发交易时才进行通讯连接交易完成后马上断开连接。此种方式经常使用于一点对多点 通讯。比方多个Client连接一个Server. 二 什么时候须要考虑粘包问题? 1:假设利用tcp每次发送数据就与对方建立连接然后两方发送完一段数据后就关闭连接这样就不会出现粘包问题由于仅仅有一种包结构,类似于http协议。关闭连接主要要两方都发送close连接參考tcp关闭协议。如A须要发送一段字符串给B。那么A与B建立连接然后发送两方都默认好的协议字符如hello give me sth abour yourself然后B收到报文后就将缓冲区数据接收,然后关闭连接这样粘包问题不用考虑到由于大家都知道是发送一段字符。 2假设发送数据无结构如文件传输这样发送方仅仅管发送接收方仅仅管接收存储就ok。也不用考虑粘包 3假设两方建立连接须要在连接后一段时间内发送不同结构数据如连接后有好几种结构 1)hello give me sth abour yourself 2)Dont give me sth abour yourself 那这种话假设发送方连续发送这个两个包出去接收方一次接收可能会是hello give me sth abour yourselfDont give me sth abour yourself 这样接收方就傻了究竟是要干嘛不知道由于协议没有规定这么诡异的字符串所以要处理把它分包怎么分也须要两方组织一个比較好的包结构所以一般可能会在头加一个数据长度之类的包以确保接收。 三 粘包出现原因在流传输中出现。UDP不会出现粘包。由于它有消息边界(參考Windows 网络编程) 1 发送端须要等缓冲区满才发送出去造成粘包 2 接收方不及时接收缓冲区的包。造成多个包接收 解决的方法 为了避免粘包现象可採取下面几种措施。一是对于发送方引起的粘包现象。用户可通过编程设置来避免TCP提供了强制数据马上传送的操作指令pushTCP软件收到该操作指令后。就马上将本段数据发送出去而不必等待发送缓冲区满二是对于接收方引起的粘包则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施使其及时接收数据从而尽量避免出现粘包现象。三是由接收方控制将一包数据按结构字段人为控制分多次接收然后合并通过这样的手段来避免粘包。 以上提到的三种措施。都有其不足之处。第一种编程设置方法尽管能够避免发送方引起的粘包但它关闭了优化算法降低了网络发送效率影响应用程序的性能一般不建议使用。另外一种方法仅仅能降低出现粘包的可能性但并不能全然避免粘包当发送频率较高时或因为网络突发可能使某个时间段数据包到达接收方较快接收方还是有可能来不及接收。从而导致粘包。第三种方法尽管避免了粘包但应用程序的效率较低对实时应用的场合不适合。 相关文章截取 一个包没有固定长度以太网限制在461500字节1500就是以太网的MTU超过这个量TCP会为IP数据报设置偏移量进行分片传输如今一般可同意应用层设置8kNTFS系的缓冲区8k的数据由底层分片而应用看来仅仅是一次发送。windows的缓冲区经验值是4k,Socket本身分为两种。流(TCP)和数据报(UDP)你的问题针对这两种不同使用而结论不一 样。甚至还和你是用堵塞、还是非堵塞Socket来编程有关。 1、通信长度这个是你自己决定的没有系统强迫你要发多大的包实际应该依据需求和网络状况来决定。对于TCP这个长度能够大点。但要知道Socket内部默认的收发缓冲区大小大概是8K你能够用SetSockOpt来改变。但对于UDP就不要太大。一般在1024至10K。注意一点。你不管发多大的包IP层和链路层都会把你的包进行分片发送。一般局域网就是1500左右广域网就仅仅有几十字节。分片后的包将经过不同的路由到达接收方。对于UDP而言。要是当中一个分片丢失那么接收方的IP层将把整个发送包丢弃这就形成丢包。显然要是一个UDP发包佷大。它被分片后链路层丢失分片的几率就佷大。你这个UDP包。就佷easy丢失可是太小又影响效率。最好能够配置这个值以依据不同的环境来调整到最佳状态。 send()函数返回了实际发送的长度在网络不断的情况下它绝不会返回(发送失败的)错误最多就是返回0。对于TCP你能够字节写一个循环发送。当send函数返回SOCKET_ERROR时才标志着有错误。但对于UDP你不要写循环发送。否则将给你的接收带来极大的麻烦。所以UDP须要用SetSockOpt来改变Socket内部Buffer的大小以能容纳你的发包。明白一点TCP作为流发包是不会整包到达的而是源源不断的到。那接收方就必须组包。而UDP作为消息或数据报它一定是整包到达接收方。 2、关于接收一般的发包都有包边界首要的就是你这个包的长度要让接收方知道于是就有个包头信息对于TCP接收方先收这个包头信息。然后再收包数据。一次收齐整个包也能够可要对结果是否收齐进行验证。这也就完毕了组包过程。UDP那你仅仅能整包接收了。要是你提供的接收Buffer过小。TCP将返回实际接收的长度余下的还能够收而UDP不同的是。余下的数据被丢弃并返回WSAEMSGSIZE错误。注意TCP。要是你提供的Buffer佷大那么可能收到的就是多个发包。你必须分离它们。还有就是当Buffer太小而一次收不完Socket内部的数据那么Socket接收事件(OnReceive)可能不会再触发使用事件方式进行接收时密切注意这点。这些特性就是体现了流和数据包的差别。 相关參考文章http://www.cnblogs.com/alon/archive/2009/04/16/1437600.html
