>>> If you can come up with a *nice* approach that isn't excessive for
>>> conformant servers, then I think we can consider including it.
>
>> should I assume that detecting the collision and repeating PASV is -not-
>> nice?
>
> It depends on what kind of code you need to put into libcurl to make it do
> so. I can honestly not think of a nice way.
from a functional point of view, the minimal work would be to:
- keep a dictionary of out-going not-yet connected ftp data connections (is
there already something like that for the PORT commands, to allocate the
port to which should connect the server?)
- when receiving EPSV/PASV response, check if the response if there, if it
is the case, restart both.
- when a data connection is actually connected or the easy dies for any
reason, the dictionary entry should be removed

to have this working properly, the dictionary-like structure should be
shared amongst all the easy (and as such would need to be thread safe).
most of this could probably be built on top of existing code (there is
already locking I think, a dictionary-like structure (for DNS resolve)), so
its probably mostly re-use, some lines in EPSV/PASV code + easy deletion and
a global.

if not putting that inside libcurl (and/or public libcurl), how could I put
it outside?
I could still keep the modifs for me, but it would be a hassle to merge :(

Armel
Received on 2006-08-24