I'm looking into the bind address port patch. While doing some
research on the feature, I found this entry in the Socket FAQ at
<http://www.ibrado.com/sock-faq/#faq37>:
6. Should I bind() a port number in my client program, or let the
system choose one for me on the connect() call?
From Andrew Gierth ([EMAIL PROTECTED]):
** Let the system choose your client's port number **
[ ... irrelevant (to us) reasoning elided ... ]
If, in a client, you use the naive scheme of starting at a fixed
port number and calling bind() on consecutive values until it
works, then you buy yourself a whole lot of trouble:
The problem is if the server end of your connection does an active
close. (E.G. client sends 'QUIT' command to server, server
responds by closing the connection). That leaves the client end of
the connection in CLOSED state, and the server end in TIME_WAIT
state. So after the client exits, there is no trace of the
connection on the client end.
Now run the client again. It will pick the same port number, since
as far as it can see, it's free. But as soon as it calls
connect(), the server finds that you are trying to duplicate an
existing connection (although one in TIME_WAIT). It is perfectly
entitled to refuse to do this, so you get, I suspect, ECONNREFUSED
from connect(). (Some systems may sometimes allow the connection
anyway, but you can't rely on it.)
This problem is especially dangerous because it doesn't show up
unless the client and server are on different machines. (If they
are the same machine, then the client won't pick the same port
number as before). So you can get bitten well into the development
cycle (if you do what I suspect most people do, and test client &
server on the same box initially).
Even if your protocol has the client closing first, there are
still ways to produce this problem (e.g. kill the server).
Turi, unless I'm mistaken, your implementation works as the one Andrew
is warning against. I'm not sure if the case he's describing can
occur in Wget, but it's worth considering. Perhaps Wget should,
instead of trying ports in succession, choose a random port between
port_lo and port_hi? That would make the problem described above much
less probable.
