mDNS测试双套接字（含异步）数据接收延迟问题咨询

让我来帮你拆解这两个mDNS测试里碰到的问题，都是实际开发中很典型的场景：

这本质上是多播套接字的配置问题。mDNS的应答报文是发送到多播地址224.0.0.251:5353的，而你的请求套接字如果没做正确的多播配置，根本就收不到这个地址的报文：

• 如果你把请求套接字绑定到了某个特定的本地单播IP（比如192.168.1.100），它只能接收发送到这个单播IP的报文，对多播地址224.0.0.251的报文会直接忽略；
• 另外，套接字必须明确加入224.0.0.251这个多播组，系统内核才会把对应多播报文递交给它。

解决思路：

• 把请求套接字绑定到通配地址0.0.0.0:5353（或者你发送请求用的端口），这样它能接收所有IP上的对应端口报文；
• 通过setsockopt调用加入多播组：比如在Linux下用IP_ADD_MEMBERSHIP选项，指定多播地址224.0.0.251和本地网卡设备；Windows下对应IP_ADD_MEMBERSHIP或者IPV6_ADD_MEMBERSHIP（如果用IPv6）。

这大概率是线程阻塞导致的异步逻辑无法调度。你的FindIP()是同步实现的——它会一直阻塞到超时时间结束，而异步嗅探的ClassSniffer如果和FindIP()运行在同一个线程里，那线程被同步套接字的阻塞调用占住了，根本没法处理异步嗅探的事件（比如监听套接字的可读事件），直到同步超时结束，线程才会回到嗅探的逻辑上。

举个例子：如果你的代码是在主线程里先调用FindIP()，然后再处理嗅探的异步事件，那FindIP()的超时会直接卡住主线程；哪怕你是用了异步IO模型（比如select/epoll），但如果把同步套接字的超时逻辑放到了事件循环的同一个线程里，也会阻塞整个循环。

解决思路：

• 把FindIP()的同步请求逻辑放到单独的线程里执行，和ClassSniffer的异步嗅探线程分离，互不干扰；
• 把FindIP()改成非阻塞模式，将其套接字加入到异步嗅探的事件循环中（比如和嗅探套接字一起放到epoll/select的监听集合里），用事件驱动的方式处理请求和应答，避免阻塞。

内容的提问来源于stack exchange，提问作者Gigi