分类：
2010-09-23 15:34:53
SO_BINDTODEVICE 套接口选项
2008-03-31 11:23
|
1. 起因 事情的起因是我准备用两个CDMA modem来拓展点对点连接的带宽，并且希望藉此实现两个modem之间的负载均衡。但是不幸的是，联通公司的接入设备不支持Multilink-PPP。于是，没有办法，我只好自己来实现负载均衡。实现负载均衡的办法有几种，网络上给出的一种办法是采用iproute2来完成包级别的负载均衡，这是在内核一级实现的。但是我并不想把一切都交给内核去完成，我希望能够自己控制每一个modem上的流量。那么，我应该怎么办呢？ 2. 解决方案 一开始，我想到的办法是创建两个套接口，然后将每个套接口都绑定到一个本地IP地址上，我以为这样将会导致数据从所绑定的IP地址所在的网络设备上发出去。但是实践证明这种想法是错误的。因为每次在发送数据包之前，内核都要查找路由表来决定从哪个网络接口上发送数据包。一旦找到一个合适的路由表项，就从该路由表项所指出的网络接口上将数据包发送出去。这样，就有一个问题，由于路由表是高速缓存的，因此每次发送数据包之后，发送数据包的那个接口将会有更大的机会被内核再一次选中。在最坏的情况下，将导致一个modem忙得不可开交，而另一个modem却“无人问津”。这显然违背了我的初衷。试验结果表明，当一个modem上发送了几百KB的数据之后，另外一个上仍然只发送了几十个B。看来，此路不通！ 循着上述思路，一种稍微令人错愕的做法是每次发送数据包之前，都先调整路由表。调整路由表是很容易做到的。但是这样做的话也实在太麻烦了一点，所以，此想法也被我抛弃了。我甚至没有测试此法是否可行，但是从理论上来说是行得通的。而且，在网上介绍的方法中，路由级别的负载均衡好像就是这样来实现的，不过，仅仅是好像而已，我并没有深究。 几番尝试未果之后，我把《UNIX网络编程》搬了出来，把UDP有关的部分细细地筛了一遍。只发现了一个可能有作用的地方：可以通过setsockopt()设置一个套接口选项：SO_DONTROUTE，但是对该选项的作用说得比较含糊。含糊归含糊，我还是实际尝试了一下，结果仍然是不行，原因未知。 于是，我不得不回到Linux本身，对着浩浩荡荡的一大堆man手册读起来。当我看到socket(7)的时候，忽然看到了一个令我眼前一亮的套接口选项：SO_BINDTODEVICE。从字面上看，这个选项应该就是我要的了。后来的试验结果证明事实的确如此。 在socket(7)中对该套接口选项的说明如下： SO_BINDTODEVICE Bind this socket to a particular device like "eth0", as specified in the passed interface name. If the name is an empty string or the option length is zero, the socket device binding is removed. The passed option is a variable-length null terminated interface name string with the maximum size of IFNAMSIZ. If a socket is bound to an interface, on 这里，我是直接照搬过来的。不过，最后的那个bind(8)肯定是错的，很显然应该是bind(2)才对。不管它，这不是我现在要解决的事情。这段话的中心意思是：当套接口被绑定到指定的网络设备接口之后，只有来自该设备的数据包才会被套接口处理。那么，如果是套接口向外发送数据包呢？是否也只会从该网络接口发出呢？可恶的是，这里没有说。不过没关系，我们试验一下就知道了。 一开始，我想当然地以为可以像下面这样： char *dev = "ppp0"; int sock1 = socket(AF_INET, SOCK_DGRAM, 0); setsockopt(sock1, SOL_SOCKET, SO_BINDTODEVICE, dev, sizeof(dev)); 然而，实践再一次证明我想错了。但是我能有什么办法呢，socket(7)中的说明写得就是这么晦涩，我看不出端倪来也是情有可原的。不过，有google在手，这点小问题我又何惧之有？于是google之，很快就发现了问题的症结所在：在Linux下，对网络设备的引用都是通过struct ifreq来完成的。在netdevice(7)中对该结构体的说明如下： struct ifreq { char ifr_name[IFNAMSIZ];/* Interface name */ union { struct sockaddrifr_addr; struct sockaddrifr_dstaddr; struct sockaddrifr_broadaddr; struct sockaddrifr_netmask; struct sockaddrifr_hwaddr; short ifr_flags; int ifr_ifindex; int ifr_metric; int ifr_mtu; struct ifmapifr_map; char ifr_slave[IFNAMSIZ]; char ifr_newname[IFNAMSIZ]; char * ifr_da }; }; 这里，我只需要ifr_name这个成员域就够了。代码修改成了下面这样： struct ifreq if_ppp0; struct ifreq if_ppp1; strncpy(if_ppp0.ifr_name, "ppp0", IFNAMSIZ); strncpy(if_ppp1.ifr_name, "ppp1", IFNAMSIZ); sock1 = socket(AF_INET, SOCK_DGRAM, 0); sock2 = socket(AF_INET, SOCK_DGRAM, 0);
if (setsockopt(sock1, SOL_SOCKET, SO_BINDTODEVICE, (char *)&if_ppp0, sizeof(if_ppp0)) < 0) { /*error handling*/ } if (setsockopt(sock2, SOL_SOCKET, SO_BINDTODEVICE, (char *)&if_ppp1, sizeof(if_ppp1)) < 0) { /*error handling*/ } 然后，在程序的主体部分，每次在sock1上发送一个数据包，同时也就会在sock2上发送一个数据包，并且程序中没有任何接收数据的动作。由于所有数据包的大小都是相等的。因此可以预计在两个网络接口上发送的数据量应该相差不大才对。测试结果有力地支持了这一猜想：在运行程序一段时间后，接口ppp0上发送的数据量为702KB，而ppp1接口上发送的数据量为895KB。虽然仍然相差了将近200KB，但是无论如何，比起原来的情况已经提高了不少。至于为什么会有这样200KB的差距，作者也正在找原因。 3. 更多结论 针对SO_BINDTODEVICE套接口选项，作者在全面阅读man手册之后，得出的结论如下： （1） 对于TCP套接口、UDP套接口、RAW套接口，可以通过SO_BINDTODEVICE套接口选项将套接口绑定到指定的网络接口上。绑定之后，套接口的所有数据包收发都只经过指定的网络接口； （2） 对于PACKET类型的套接口，不能通过SO_BINDTODEVICE绑定到指定的网络接口上，而要通过bind(2)来与特定的网络接口绑定，所用的套接口地址结构为struct sockaddr_ll，此套接口地址结构是链路层的地址结构，独立于具体的网络设备。比如，该地址结构既可以用于表示PPP设备，也能用于表示ethernet设备。 （3） SO_BINDTODEVICE套接口选项只适用于Linux系统。如果要编写运行在多操作系统平台上的程序，不能依赖SO_BINDTODEVICE来完成套接口与具体设备的绑定。 不过，作者并没有对TCP套接口和RAW套接口进行测试。对于PACKET套接口，上述结论是可信的，因为我阅读了dhcpd的源代码，发现对于PACKET套接口的确是通过bind(2)绑定到指定的网络接口上 |
