Thanks Bill for this very interesting explanations.
However, the default data port for the client is the ephemeal port used by the
control channel, not 21.
this does'n solve the problem but it makes it less critical. indeed, if the
server
specifies the SO_REUSEADDR option, then it can bind to port 20 even if
another connection is active or dying (ie in the TIME_WAIT state).
If this is done, then your example with multiple processes will never happen.
(except if the server code doesn't use the reuseaddr option).
The problem occurs if the server tries to connect to te client's port while
another connection is active (i.e. socket not closed) or is dying (sockets
closed
but still in the TIME_WAIT state).
in the case of a dying connection, it can retry until the time_wait "expires".
this will introduce a delay of up to 4 minutes on "normal" systems. that's bad,
but not critical (but the server must retry!). [as far as I know,
theGauntlet doesn't
retry, so if the bind fails, it will connect and thus use a random port. I
don't think
this is documented:)
The only case when the problem is really critical is when two or more
connections
sing the same addresses&ports on both sides must exist simultaneously. such
connections are only possible in the case of a multithreaded server that
tries to
send many files simultaneously.
All this means tha the problem is not critical but annoying.
Anyway, I agree that CKP decision is a bad one...
chers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
