标签：缓冲 mat 数据丢失 协议 style 指定 linux udp协议 mac
1.UDP套接字
udp服务端:
1 ss = socket() #创建一个服务器的套接字 2 ss.bind() #绑定服务器套接字 3 inf_loop: #服务器无限循环 4cs = ss.recvfrom()/ss.sendto() # 对话(接收与发送) 5 ss.close() # 关闭服务器套接字
udp客户端:
1 cs = socket() # 创建客户套接字 2 comm_loop: # 通讯循环 3 cs.sendto()/cs.recvfrom() # 对话(发送/接收) 4 cs.close() # 关闭客户套接字
2.recv与recvfrom的区别:
part1:
发消息都是将数据发送到己端发送缓冲中,手消息都是从己端的缓冲区中收
tcp:send发消息,recv收消息
udp:sendto发消息,recvfrom收消息
part2:
tcp是基于数据流的,而udp是基于数据报的
send(bytes_data):发送数据流,数据流bytes_data若为空,自己这段的缓冲区也为空,操作系统不会控制tcp协议发空包
sendinto(bytes_data,ip_port):发送数据报,bytes_data为空,还有ip_port,所有即便是发送空的butes_data,数据报其实也不是空的,自己这端的缓冲区收到内容,操作系统就会控制udp协议发包.
part3:
1.tcp协议:
(1)如果收消息缓冲区里的数据为空,那么recv就会阻塞(阻塞很简单,就是一直在等着接收)
(2)只不过tcp协议的客户端send一个空数据就是真的空数据,客户端即使有无穷个send空,也跟没有一个样.
(3)tcp基于链接通信
*基于链接,则需要listen(backlog),指定半连接池的大小
*基于链接,必须先运行的服务端,然后客户端发起链接请求
*对于Mac空系统:如果一段断开了链接,那另外一端的链接也跟着完蛋recv将不会阻塞,收到的是空(解决方法是:服务端在收消息后加上if判断,空消息就break掉通信循环)
*对于Windows/Linux系统:如果一端断开了链接,那另外一端的链接也跟着完蛋recv将不会阻塞,收到的是空(解决方法:服务端通信循环内加异常处理,捕捉到异常后就break掉通讯循环)
2.udp协议
(1)如果收消息缓冲区里的数据为"空",recvfrom也会阻塞
(2)支部会udp协议的客户端sendinto一个空数据并不是真的空数据(包含:空数据+地址信息,得到的报仍然不会为空),所以客户端只要有一个sendinto(不管是否发送空数据,都不会真的空数据),服务端就可以recvfrom到数据.
(3)udp无链接
*无链接,因而无需listen(backlog),更加没有什么连接池之说了
*无链接,udp的sendinto不用管是否有一个正在运行的服务端,可以己端一个劲的发消息,只不过数据丢失
*recvfrom收的数据小于sendinto发送的数据时,在Mac和Linux系统上数据直接丢失,在Windows系统上发送的比接受的大直接报错
*只有sendinto发送数据没有recvfrom收数据,数据丢失
PS:
1.你单独运行上面的udp的客户端,你发现并不会报错,相反tcp却会报错,因为udp协议只负责把包发出去,对方收不收,我根本管不着,而tcp是基于链接的,必须有一个服务端先运行着,客户端去跟服务端建立连接然后依托于连接才能传递消息,任何一方试图把连接摧毁都会导致对方程序崩溃
2.上面的udp程序,你注释任何一条客户端的sendinto,服务端都会卡住,为什么?因为服务端有几个recvfrom就要对应几个sendinto,哪怕是sendinto(b‘‘)那也要有.
3.粘包现象:
只有TCP有粘包现象,UDP永远不会粘包!
所谓的粘包问题主要还是因为接收对方不知道消息之间的界限,不知道一次性提取多少字节的数据造成的.
以下情况会发生粘包:
1.发送端需要等缓冲区满才发送出去,造成粘包(发送数据时间间隔很短,数据量很小,会合到一起,产生粘包)
2.接收方不及时接收缓冲区的包,造成多个包接收(客户端发送一端数据,服务端只收了一小部分,服务端下次再收的时候还是从缓冲区拿上次遗留的数据,产生粘包)
4.解决粘包方法:
struct模块
该模块可以把一个类型,如数字,转成固定长度的bytes
>>>Struct.pack(‘i‘,111111111111)
struct.error:‘i‘ format requires -2147483648 <= number <=2147483647 #这个是范围
标签：缓冲 mat 数据丢失 协议 style 指定 linux udp协议 mac
原文地址：http://www.cnblogs.com/gz369521/p/6808351.html
