RE: FTP third party transfer (proxy) support.
Date: Tue, 1 Jun 2004 11:20:08 +0200 (CEST)
On Tue, 1 Jun 2004, Alexander Krasnostavsky wrote:
> OK. Now I understand. The problem appeared within my patch. For 3rd party
> transfer, there is a need to keep 2 'data' structs (SessionHandle), one for
> each connection.
I disagree. There's no "need" to have two such structs. It is however the way
you opted to write your code. The SessionHandle struct is the base curl handle
struct and it is fairly big (30-40K or something), I think we should be more
> So in ConnectionExists(), if there is more than one open connection,
> conn_temp will be pointed to some connection in data->state.connects, but
> the 'data' won't be the same.
Then you've altered the whole concept of connection reuse and I'd say you are
out on very deep water. I wouldnt't go swimming in those places! ;-)
I suggest you find an alternative way of doing this. We cannot have
cached/re-used connections over multiple SessionHandle structs (at least not
without much more careful planning and usage of the share interface concepts).
> Therefore refreshing the user data ('set' struct) in the primary connection
> will solve the problem. Do you have any other way to handle this?
You're hitting exactly the problem I mentioned when I noticed that you cloned
the data struct and assume that things will work fine from there on. Since the
code doesn't know if it works on a clone or on the original struct, it can't
work correctly and will end up free()ing pointers twice and similar.
I can't see how you can easily work around this problem when you clone the
-- Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se Dedicated custom curl help for hire: http://haxx.se/curl.htmlReceived on 2004-06-01