Linux下端口复用(SO_REUSEADDR与SO_REUSEPORT)

解决性参考：Currently, Linux does not allow reuse of same local port for both TCP server and TCP client.而且小测试程序能够成功，和我的库测试程序的差别也就在这一点了，因此接受连接和发起连接的端口分开即可。

其他资料：

这个是捣乱最大的：http://www.ajaxstu.com/Linuxbiancheng/294968.html　请问：linux难道没有端口重用吗？我用SO_REUSEPORT报找不到

已经搞定，需要改/usr/include/asm/socket.h:/* To add :#define SO_REUSEPORT 15 */

http://hi.baidu.com/qiaoyong/blo ... b1f4190ff47707.html

freebsd与linux下bind系统调用小结

只考虑AF_INET的情况（同一端口指ip地址与端口号都相同）
1.freebsd支持SO_REUSEPORT和SO_REUSEADDR选项,而linux只支持SO_REUSEADDR选项。
2.freebsd下,使用SO_REUSEPORT选项，两个tcp的socket可以绑定同一个端口；同样，使用SO_REUSEPORT选项，两个udp的socket可以绑定同一个端口。
3.linux下，两个tcp的socket不能绑定同一个端口；而如果使用SO_REUSEADDR选项，两个udp的socket可以绑定同一个端口。
4.freebsd下，两个tcp的socket绑定同一端口，只有第一个socket获得数据。
5.freebsd下，两个udp的socket绑定同一端口，如果数据包的目的地址是单播地址，则只有第一个socket获得数据，而如果数据包的目的地址是多播地址，则两个socket同时获得相同的数据。
6.linux下，两个udp的socket绑定同一端口，如果数据包的目的地址是单播地址，则只有最后一个socket获得数据，而如果数据包的目的地址是多播地址，则两个socket同时获得相同的数据。

http://cache.baidu.com/c?m=9d78d ... er=baidu&fast=y
Unix网络API

SO_REUSEADDR和SO_REUSEPORT
SO_REUSEADDR提供如下四个功能：
SO_REUSEADDR允许启动一个监听服务器并捆绑其众所周知端口，即使以前建立的将此端口用做他们的本地端口的连接仍存在。这通常是重启监听服务器时出现，若不设置此选项，则bind时将出错。
SO_REUSEADDR允许在同一端口上启动同一服务器的多个实例，只要每个实例捆绑一个不同的本地IP地址即可。对于TCP，我们根本不可能启动捆绑相同IP地址和相同端口号的多个服务器。
SO_REUSEADDR允许单个进程捆绑同一端口到多个套接口上，只要每个捆绑指定不同的本地IP地址即可。这一般不用于TCP服务器。
SO_REUSEADDR允许完全重复的捆绑：当一个IP地址和端口绑定到某个套接口上时，还允许此IP地址和端口捆绑到另一个套接口上。一般来说，这个特性仅在支持多播的系统上才有，而且只对UDP套接口而言（TCP不支持多播）。
SO_REUSEPORT选项有如下语义：
此选项允许完全重复捆绑，但仅在想捆绑相同IP地址和端口的套接口都指定了此套接口选项才性。
如果被捆绑的IP地址是一个多播地址，则SO_REUSEADDR和SO_REUSEPORT等效。
使用这两个套接口选项的建议：
在所有TCP服务器中，在调用bind之前设置SO_REUSEADDR套接口选项；
当编写一个同一时刻在同一主机上可运行多次的多播应用程序时，设置SO_REUSEADDR选项，并将本组的多播地址作为本地IP地址捆绑。

What is the difference between SO_REUSEADDR and SO_REUSEPORT?
from：UNIX Socket FAQ

SO_REUSEADDR allows your server to bind to an address which is in aTIME_WAIT state. It does not allow more than one server to bind to thesame address. It was mentioned that use of this flag can create asecurity risk because another server can bind to a the same port, bybinding to a specific address as opposed to INADDR_ANY. TheSO_REUSEPORT flag allows multiple processes to bind to the same addressprovided all of them use the SO_REUSEPORT option.

From Richard Stevens ([e-mail]):

This is a newer flag that appeared in the 4.4BSD multicasting code(although that code was from elsewhere, so I am not sure just whoinvented the new SO_REUSEPORT flag).

What this flag lets you do is rebind a port that is already in use, butonly if all users of the port specify the flag. I believe the intent isfor multicasting apps, since if you're running the same app on a host,all need to bind the same port. But the flag may have other uses. Forexample the following is from a post in February:

From Stu Friedberg ([e-mail]):

SO_REUSEPORT is also useful for eliminating the try-10-times-to-bindhack in ftpd's data connection setup routine. Without SO_REUSEPORT,only one ftpd thread can bind to TCP (lhost, lport, INADDR_ANY, 0) inpreparation for connecting back to the client. Under conditions ofheavy load, there are more threads colliding here than the try-10-timeshack can accomodate. With SO_REUSEPORT, things work nicely and the hackbecomes unnecessary.

I have also heard that DEC OSF supports the flag. Also note that under4.4BSD, if you are binding a multicast address, then SO_REUSEADDR iscondisered the same as SO_REUSEPORT (p. 731 of "TCP/IP Illustrated,Volume 2"). I think under Solaris you just replace SO_REUSEPORT withSO_REUSEADDR.

From a later Stevens posting, with minor editing:

Basically SO_REUSEPORT is a BSD'ism that arose when multicasting wasadded, even thought it was not used in the original Steve Deering code.I believe some BSD-derived systems may also include it (OSF, nowDigital Unix, perhaps?). SO_REUSEPORT lets you bind the same address*and* port, but only if all the binders have specified it. But whenbinding a multicast address (its main use), SO_REUSEADDR is consideredidentical to SO_REUSEPORT (p. 731, "TCP/IP Illustrated, Volume 2"). Sofor portability of multicasting applications I always use SO_REUSEADDR.