udp接收队列以及多次初始化的测试

这一段时间基于udp的数据重放的过程中图像总是卡死，发现recv Q满了，但是不知道具体原因是啥，这里就先进行了udp的接收测试。

一. 正常测试 

1. send端每次发送1k，发送频率50hz；

2. recv端每次接受1k，接受频率5hz；
3. watch -n 1 netstat -anu 显示recv进程对应8888端口的recv Q在207000到162000之间波动，不会卡死。recv Q 的上限是207000左右。通过分析结果可以发现，当recv q满了之后，recv从队列里面拿出1k后，就会从接收发送端的1k进入队列，而是recv持续从队列里面拿数据，直到recv Q 降到162000左右，也就是队列占用率达到80%之后，才会接受send端发过来的数据。

二. 当recv端cnt==800时，执行socket重新初始化

 if(cnt == 800)

       {

          serfd=socket(AF_INET,SOCK_DGRAM,0);

           printf("serfd = %d\n",serfd);

          // ret=bind(serfd,(struct sockaddr *)&seraddr,sizeof(seraddr));

       }

1. socket初始化

  无论是否执行bind操作，接收端都会卡住，接收队列都会满。同时/proc/pid/fd下面会新增一个socket文件，对应的fd为4。如果执行bind，则会返回绑定失败，端口被占用。

原因：经过上述的if语句后，serfd已经变成了4，对应的是一个新的socket文件，也就是说recv端会有一个新的接收队列，只是没有数据发送到这个新的队列。send端发送的数据依旧发送到serfd=3对应的队列中，但该队列没有人去读取了，造成recv Q 满了。表象就是卡住了，实际上是因为serfd=4对应的队列中没有数据。

    2. socket初始化，同时将recvfrom函数中用到的serfd换成3这个常量

除了上述修改外，如果把recvfrom的serfd换成常量3，则虽然新生成4对应的fd，但是数据依然从3对应的队列中获取，也不会卡住，只是4对应队列中没有数据。