[
https://issues.apache.org/jira/browse/TS-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582134#comment-14582134
]
Sudheer Vinukonda commented on TS-3685:
---------------------------------------
ah, it seems that on linux 3.9+, SO_REUSEPORT allows the same combination of
*source address + port* to be reused by more than one socket. So, the option
would still help.
http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
{code}
Linux
Prior to Linux 3.9, only the option SO_REUSEADDR existed. This option behaves
generally the as in BSD with two important exceptions. One exception is that a
if a listening (server) TCP socket is already bound to a wildcard IP address
and a specific port, no other TCP socket can be bound to the same port,
regardless whether either one or both sockets have this flag set. Not even if
it would use a more specific address (as is allowed in case of BSD). This
restriction does not apply to non-listening (client) TCP sockets and it is also
possible to first bind a listening TCP socket to a specific IP address and port
combination and later on bind another one to a wildcard IP address and the same
port. The second exception is that for UDP sockets this option behaves exactly
like SO_REUSEPORT in BSD, so two UDP sockets can be bound to exactly the same
address and port combination as long as both had this flag set before they were
bound.
Linux 3.9 added the option SO_REUSEPORT to Linux as well. This option allows
two (or more) sockets, TCP or UDP, listening (server) or non-listening
(client), to be bound to exactly the same address and port combination as long
as all sockets (including the very first one) had this flag set prior to
binding them. To prevent "port hijacking", there is one special limitation,
though: All sockets that want to share the same address and port combination
must belong to processes that share the same effective user ID! So one user
cannot "steal" ports of another user. Additionally the kernel performs some
"special magic" for SO_REUSEPORT sockets that isn't found in any other
operating system so far: For UDP sockets, it tries to distribute datagrams
evenly, for TCP listening sockets, it tries to distribute incoming connect
requests (those accepted by calling accept()) evenly across all the sockets
that share the same address and port combination. That means while it is more
or less random which socket receives a datagram or connect request in other
operating systems that allow full address reuse, Linux tries to optimize
distribution so that, for example, multiple instances of a simple server
process can easily use SO_REUSEPORT sockets to achieve a kind of simple load
balancing and that absolutely for free as the kernel is doing "all the hard
work" for them.
{code}
> traffic_manager can't bind to port 80 sometimes.
> ------------------------------------------------
>
> Key: TS-3685
> URL: https://issues.apache.org/jira/browse/TS-3685
> Project: Traffic Server
> Issue Type: Bug
> Components: Manager
> Reporter: Sudheer Vinukonda
>
> During new install/updates sometimes, when ATS is restarted too quickly
> multiple times, we occasionally end up with the below error, causing ATS not
> to come up:
> {code}
> [Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} NOTE:
> [LocalManager::listenForProxy] Listening on port: 80
> [Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} NOTE:
> [LocalManager::listenForProxy] Listening on port: 443
> [Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} ERROR: [bindProxyPort] Unable
> to bind socket: 80 : Address already in use
> {code}
> This is quite annoying and inconvenient since it blocks ATS from coming up
> (sometimes for very long) until a reboot or some other deep clean up is
> performed.
> Would like to add the socket option *SO_REUSEPORT* to the socket doing the
> proxy port binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
