局域网UDP组播与设备自动发现测试

除了AirKiss、SmartConfig此类网络应用技巧，我们需要尽可能利用手头开源硬件来测试传统的TCP/UDP连接。其中UDP的组播在物联网应用中有一定的重要意义。主要的UDP组播应用协议有：

mDNS
SSDP/uPnP
Apple AirPlay
DLNA，各类媒体播放器

IP组播与IGMP

IGMP（Internet Group Management Protocol）协议告诉路由器，在所在子网内有客户端对发送到某一个组播组的数据感兴趣，这样当该组的数据到达后，路由器会转送给所有感兴趣的客户端。

Windows 失败原因

之间发现，凡是Windows主机参与的IP组播都是失败的。首先怀疑WiFi路由器禁止了IGMP和uPnP服务，测试下来，同一WiFi局域网内，电视和手机的媒体推送没有任何问题。

但即便开启了Windows的Bonjour服务，关闭了防火墙，依然失败。推测Windows的网路配置上依然存在问题，这是Windows 10以及Ubuntu子系统无法侦听和推送多播报文的主要原因。Windows 10自带的Ubuntu子系统受控于操作系统防火墙，无法收发组播报文。抛出一个错误：

allankliu@allankliu-HP:/mnt/c/Users/allankliu$ iperf -s -u -B 224.0.67.67 -i 1
bind failed: Cannot assign requested address

而运行于Windows中的虚拟机，因为其网络配置是桥接模式，Ubuntu虚拟机可以直接从路由器获得IP地址，Windows防火墙对其没有作用。是可以收发组播报文的。

今早拿Ubuntu 12.04（Windows中VirtualBox中虚拟机）和树莓派Raspbian做了测试，Linux之间组播没有任何问题。测试工具使用了iperf，下一步将采用Python socket做测试。

iperf for Linux

pi@raspberrypi ~ $ iperf -c 224.0.67.67 -u --ttl 5 -t 10
------------------------------------------------------------
Client connecting to 224.0.67.67, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 5
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.25 port 35294 connected with 224.0.67.67 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams

allankliu@ubuntu-server-vm:~$ iperf -s -u -B 224.0.67.67 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 224.0.67.67
Joining multicast group  224.0.67.67
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 224.0.67.67 port 5001 connected with 192.168.1.25 port 35294
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   128 KBytes  1.05 Mbits/sec   1.017 ms    0/   89 (0%)
[  3]  1.0- 2.0 sec   129 KBytes  1.06 Mbits/sec   0.972 ms    0/   90 (0%)
[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec   0.723 ms    0/   89 (0%)
[  3]  3.0- 4.0 sec   128 KBytes  1.05 Mbits/sec   6.029 ms    0/   89 (0%)
[  3]  4.0- 5.0 sec   128 KBytes  1.05 Mbits/sec   1.236 ms    0/   89 (0%)
[  3]  5.0- 6.0 sec   128 KBytes  1.05 Mbits/sec   2.518 ms    0/   89 (0%)
[  3]  6.0- 7.0 sec   129 KBytes  1.06 Mbits/sec   1.097 ms    0/   90 (0%)
[  3]  7.0- 8.0 sec   128 KBytes  1.05 Mbits/sec   1.024 ms    0/   89 (0%)
[  3]  8.0- 9.0 sec   128 KBytes  1.05 Mbits/sec   0.697 ms    0/   89 (0%)
[  3]  9.0-10.0 sec   128 KBytes  1.05 Mbits/sec   1.586 ms    0/   89 (0%)
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   1.577 ms    0/  893 (0%)

以上是树莓派发，Ubuntu收，反之亦然。

ESP8266

以组播为基础的mDNS/SSDP作为IoT最大的好处就是可以通过这两项服务构建起一个本地的IoT设备生态，无论是办公司、家居、工业、农业、军事等。均可以通过IPv4/v6组播实现自动接入、然后利用TCP/UDP的单播进行后续认证和协同。

ESP8266自带mDNS/SSDP例子。之所以对组播感兴趣也就是因为自己要做些产品而做得实验。

iperf的其他版本

iperf是法国人写的，除了最初的Linux，还支持32bit/64bit Windows，以及Android，iOS，Mac等，主流平台都得到了支持。如果Chrome/Android/iOS移动端的JavaScript runtime支持组播，那么甚至可以不需要Java/C/C++/Python的参与了。