Le mardi 04 janvier 2011 à 13:12 +0400, Gaspar Chilingarov a écrit :
quoted text
> Hi there!
> 
> Well, that looks strange.
> 
> On my own side I've just put workaround (manually binding to all ports
> in sequence :)
> and moved production code to FreeBSD as it has better scalable network stack.
> 
> I can see the potential problem with that bind() problem on highly
> loaded DNS servers/resolvers which establish tons of outgoing UDP
> connections.
> 
> In some cases that connections could fail and as not receiving the
> answer it is normal condition for DNS this will go totally unnoticed.
> 
> I don't think anyone will hit this bug in production environment
> except the very high load applications.

Dont mix TCP and UDP, they are not the same.

Problem with TCP is you can have TIME_WAIT sockets, disallowing a port
to be reused. Not with UDP.

The connect() [without a previous bind()], or a sendto() [without a
previous bind()] problem is more an API problem.

When kernel autobinds an UDP socket [to get a local IP/port], there is a
problem on the selection of the local address : It must be ANY_ADDR
(0.0.0.0)

While for TCP, the IP address wont change for the whole session.
Problem is : The port can really be random, while the local address
comes from routing tables. To reach one destination, we usually use one
pref IP address, even if many are available.

If you dont bind() a socket before sending an UDP frame, kernel cannot
assume the local IP address wont change later (for other sent frames, if
routing takes another path), so must use the ANY address for the port
selection done in autobind. Max 2^16-1 choices.

If you have 100 IP addresses on your machine, it doesnt change this ANY
selection [for UDP] at all.

If you need more than 2^16 local endpoints and you have more than one
external IP address, the only portable way is to use bind() yourself and
manage a pool of [tuples]. Well, this is not true for some old OSes
(Solaris 2.5.1 comes to mind with TCP sockets)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html