Linux下将套接口绑定到网络设备的方法.docx_第1页
Linux下将套接口绑定到网络设备的方法.docx_第2页
Linux下将套接口绑定到网络设备的方法.docx_第3页
Linux下将套接口绑定到网络设备的方法.docx_第4页
Linux下将套接口绑定到网络设备的方法.docx_第5页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

linux资讯:/os/linux/index.htmlLinux下将套接口绑定到网络设备的方法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, only packets received from that particular interface are processed by the socket. Note that this only works for some socket types, particularly AF_INET sockets. It is not supported for packet sockets (use normal bind(8) there).这里,我是直接照搬过来的。不过,最后的那个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_nameIFNAMSIZ;/* 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_slaveIFNAMSIZ; char ifr_newnameIFNAMSIZ; char * ifr_data; ; ;这里,我只需要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) /*error handling*/ if (setsockopt(sock2, SOL_SOCKET, SO_BINDTODEVICE, (char *)&if_ppp1, sizeof(if_ppp1) /*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来完成套接口和

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论