在本机接收UDP广播数据,会凭空多出16个字节。具体如下:环境:win2000 vc6 WSAStartup中初始化为2.2版本。一个UDP socket,绑定到 INADDR_ANY 的 S 端口,成功设置SO_BROADCAST选项后,用sendto发广播数据到 T 端口(目标IP 255.255.255.255)。设发送字节数为sendlen。在此之前已经有同一台主机上的另一个程序用UDP socket绑定到INADDR_ANY的 T 端口并处于等待接收状态(recvfrom函数),接收缓冲区长度为recvlen,此时发现一个现象:如果recvlen小于(sendlen+16),接收就会出现10040错误,如果recvlen大于等于此值,recvfrom就返回sendlen+16,前16个字节每次都一样,为(16进制):
44,72,63,6f,a,0,fa,3,b8,8,a,6e,38,3a,0,0,然后才是sendlen个发送端发送的字节。即接收的内容比发送多了16个字节,这16个字节也不象是UDP的首部或IP首部。怎么回事?是我错了还是winsock错了?
如果不用广播地址,用127.0.0.1,则一切正常,发多少个就收多少个。
我的IP是10.110.56.58,掩码是255.255.248.0,如果用主机号全1 的子网广播地址10.110.63.255,结果这个BUG还是一样存在的。

解决方案 »

  1.   

    在上面的实验中,我发现在发送数据的字节数:1、<=(1472-16)即1456字节时就会出现上面所说的多16字节的错误
    2、>1456且<=1472,情况又正常了,接收字节数和发送字节数相等了
    3、>1472,则sendto返回成功(字节数),但recvfrom收不到,还在继续阻塞。因为1472是UDP在不分片的情况下(以太网的情况下)的最大数据字段的字节数,所以估计是因为winsock发送到广播地址时不允许分片,导致第3种情况发生(当然sendto不返回错误也是一个问题)。
      

  2.   

    我在win xp下又试了一下,上面说的问题都消失了,一切正常。看来确实是win2000的bug,在win xp中改正了