Windows SSDP发现服务限制传出SSDP广播

我有一个Python应用程序，可以广播SSDP发现请求。我注意到我试图发现的设备并不总是有响应。使用Wireshark，我发现只有一些广播到达了有线电视。在一些故障排除之后，我将问题的根源隔离到SSDP发现服务——如果我禁用该服务，那么我的数据包丢失就会消失。此外，如果使用SSDP（239.255.255.250）以外的多播地址，问题也会消失。因此，SSDP显然在限制我传出的UDP广播。知道为什么吗？也许是想合并广播/限制流量？我正在使用Windows7。这个问题在OSX下不会发生

下面是一个快速测试应用程序，演示了数据包丢失-两个实例都运行在同一个系统上，发送方实例每秒发送一个数据包，接收方报告测试定义的数据包编号中的任何间隙

def testSend():
    seqNumber = 0
    while True:
        sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
        sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 1)
        sock.sendto(str(seqNumber), ("239.255.255.250", 1900))
        sock.close()
        print("Sent Seq #{:4d}  [{}]".format(seqNumber, time.ctime()))
        seqNumber += 1
        time.sleep(1)

def testReceive():
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    sock.bind(("", 1900))   
    mreq = struct.pack("4sl", socket.inet_aton("239.255.255.250"), socket.INADDR_ANY)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
    expectedSequenceNumber = 0
    while True:
        response = sock.recv(100)
        actualSequenceNumber = int(response)
        if actualSequenceNumber == expectedSequenceNumber:
            print("Good: Received Seq #{:>4s}  [{}]".format(response, time.ctime()))
        else:
            print("Bad: Expected Seq #{}, Got #{} ({} frames dropped) [{}]".format(expectedSequenceNumber, actualSequenceNumber, actualSequenceNumber - expectedSequenceNumber, time.ctime()))
        expectedSequenceNumber = actualSequenceNumber + 1

if sys.argv[1] == 'send':
    testSend()
elif sys.argv[1] == 'receive':
    testReceive()

Output on receiving side:

Good: Received Seq #   0  [Sun Sep 20 11:01:18 2015]
Good: Received Seq #   1  [Sun Sep 20 11:01:19 2015]
Good: Received Seq #   2  [Sun Sep 20 11:01:20 2015]
Good: Received Seq #   3  [Sun Sep 20 11:01:21 2015]
Good: Received Seq #   4  [Sun Sep 20 11:01:22 2015]
Bad: Expected Seq #5, Got #12 (7 frames dropped) [Sun Sep 20 11:01:30 2015]
Good: Received Seq #  13  [Sun Sep 20 11:01:31 2015]
Good: Received Seq #  14  [Sun Sep 20 11:01:32 2015]
Good: Received Seq #  15  [Sun Sep 20 11:01:33 2015]
Good: Received Seq #  16  [Sun Sep 20 11:01:34 2015]
Good: Received Seq #  17  [Sun Sep 20 11:01:35 2015]
Good: Received Seq #  18  [Sun Sep 20 11:01:36 2015]
Good: Received Seq #  19  [Sun Sep 20 11:01:37 2015]
Good: Received Seq #  20  [Sun Sep 20 11:01:38 2015]
Bad: Expected Seq #21, Got #51 (30 frames dropped) [Sun Sep 20 11:02:09 2015]
Good: Received Seq #  52  [Sun Sep 20 11:02:10 2015]
Good: Received Seq #  53  [Sun Sep 20 11:02:11 2015]
Good: Received Seq #  54  [Sun Sep 20 11:02:12 2015]
Good: Received Seq #  55  [Sun Sep 20 11:02:14 2015]
Good: Received Seq #  56  [Sun Sep 20 11:02:15 2015]
Good: Received Seq #  57  [Sun Sep 20 11:02:16 2015]
Good: Received Seq #  58  [Sun Sep 20 11:02:17 2015]
Good: Received Seq #  59  [Sun Sep 20 11:02:18 2015]
Good: Received Seq #  60  [Sun Sep 20 11:02:19 2015]
Bad: Expected Seq #61, Got #71 (10 frames dropped) [Sun Sep 20 11:02:30 2015]
Good: Received Seq #  72  [Sun Sep 20 11:02:31 2015]
Good: Received Seq #  73  [Sun Sep 20 11:02:32 2015]
Good: Received Seq #  74  [Sun Sep 20 11:02:33 2015]
Good: Received Seq #  75  [Sun Sep 20 11:02:34 2015]
Good: Received Seq #  76  [Sun Sep 20 11:02:35 2015]
Good: Received Seq #  77  [Sun Sep 20 11:02:36 2015]
Good: Received Seq #  78  [Sun Sep 20 11:02:37 2015]
Good: Received Seq #  79  [Sun Sep 20 11:02:38 2015]
Good: Received Seq #  80  [Sun Sep 20 11:02:39 2015]
Bad: Expected Seq #81, Got #110 (29 frames dropped) [Sun Sep 20 11:03:09 2015]
Good: Received Seq # 111  [Sun Sep 20 11:03:10 2015]
Good: Received Seq # 112  [Sun Sep 20 11:03:11 2015]
Good: Received Seq # 113  [Sun Sep 20 11:03:12 2015]
Good: Received Seq # 114  [Sun Sep 20 11:03:13 2015]
Good: Received Seq # 115  [Sun Sep 20 11:03:14 2015]
Good: Received Seq # 116  [Sun Sep 20 11:03:15 2015]
Good: Received Seq # 117  [Sun Sep 20 11:03:16 2015]
Good: Received Seq # 118  [Sun Sep 20 11:03:17 2015]
Good: Received Seq # 119  [Sun Sep 20 11:03:18 2015]
Bad: Expected Seq #120, Got #130 (10 frames dropped) [Sun Sep 20 11:03:30 2015]
Good: Received Seq # 131  [Sun Sep 20 11:03:31 2015]
Good: Received Seq # 132  [Sun Sep 20 11:03:32 2015]
Good: Received Seq # 133  [Sun Sep 20 11:03:33 2015]
Good: Received Seq # 134  [Sun Sep 20 11:03:34 2015]
Good: Received Seq # 135  [Sun Sep 20 11:03:35 2015]
Good: Received Seq # 136  [Sun Sep 20 11:03:36 2015]

编辑（2015年6月10日）： 我相信是我造成了这个问题。Windows SSDP发现服务会定期出现，以循环哪些接口多播数据包发出，哪些接口传入数据包发出，即使在仅配置了一个物理网络接口/联机的系统上也是如此。在我的系统上，我有一个有线以太网和两个虚拟VMware网络适配器（我没有在VM中运行-它们位于主机端，已启用但未使用）。我修改了上述实用程序的源代码，以支持配置通过setsockopt（IP_MULTICAST_IF）播放广播的接口，以及通过setsockopt（IP_ADD_MEMBERSHIP）收听广播的接口。然后，我运行了该实用程序的四个实例—一个在Inadr______________________________________________。当INADDR_ANY receiver实例开始丢失数据包时，我看到它们出现在一个VMware侦听器上。这是我的证据，证明Windows SSDP发现服务正在循环多播传输的默认适配器集。当SSDP服务被禁用时，我看不到这种情况发生。我假设发现服务这样做是为了捕获所有网络接口上的SSDP消息，尽管不清楚为什么它必须更改系统默认多播来实现这一点，而不仅仅是在系统中的每个接口上有多个套接字

---

解决方法是显式设置我为多播传输和侦听配置的接口，而不是依赖INADDR_êANY，这是处理多播的传统方法，可以在其他任何单主机操作系统平台上正常工作。请注意，不仅要显式设置发送接口，还要显式设置接收端，因为发现服务对默认接口的循环既适用于默认传输接口，也适用于IP多播成员组接受哪些接口传入数据包。

我担心您永远不会回复，但您能研究一下MiniUPNP吗？似乎它也有同样的问题。