>> OK so the plan now is first to:
>
>> - check if the 'done' bit in the request can be used to infer if the Do
>> part is completely finished
>
> Sorry, but I figured out that bit isn't reliable. It will always be set
> for this case, since when the connection is aborted Curl_done() _is_
> called and this bit gets set...
ok so we'll need to use the multi state != COMPLETED test I think.

>> - determine how the end of command buffer of the last cancelled reqsuest
>> of the reused connection can be sent (is the end of buffer already stored
>> there in connection, in this case it would be easy, else do we have to
>> add a field for that)
>
> The data is already stored so it is just a matter of checking if there is
> remaining data and if so send it.
>
> And wait for possibly still remaining incoming response data of course -
> if there is remaining outgoing data, we haven't even started receiving the
> response yet!
right

>> - detemine if we need a bit 'need_abort' on the FTP connection also
>> (which we do set if the previously cancelled request needed a data
>> connection)
>
> Yeah, but when exactly is ABOR really needed? Don't most servers detect by
> themselves when the client close down the data connection?
yes, but we may not have had the time to open it ;-)

>> - then code the cancel part in Curl_ftp_done( )
>
> Really? If the connection won't be re-used again, doing lengthy stuff in
> the done phase seems to be done a bit in vain. Isn't it just as best to
> just do all this magic if the connection is to be re-used?
>
> Of course the connection would have to be marked somehow in the done
> function about these conditions.
yes that's what i wnated to mean

> Ehm, no. We might need to at least read out the whole response on the
> control connection already in the done function, as I believe our
> "connection is dead" detection won't work properly if we get data on a
> connection that is supposed to be idle (which unused connections are
> supposed to be).
so maybe what I called the state FTP_REUSE (finishing send, then finishing
receive) would be put into curl_ftp_done?
is it possible to still do non-blocking stuff in the curl_ftp_done? because
i would prefer to avoid any wait during this period (parallel downloads
would suffer).

>> - and the re-use part probably near the start (temporaly speaking) of
>> Curl_ftp_do, with some new ftpstate values: FTP_REUSE (sending of last
>> command), FTP_ABOR (to abort data connection).
>>
>> am i in the right direction?
>
> Yes I think you are. A tricky part might be to write up some good test
> cases for this to repeat this behavior on the demand so that we can test
> and make sure the code is working properly...
yes, it won't be easy... we'll have to handle several requests (the
canceled, the reused), and simulate cancellation at various places.

would this totally different direction be meaningful to you?
- we could have a CURLOPT_CANCEL which could be set to 1 while a CURL easy
handle is running, in this case, the current request would get ended as fast
as possible. we could have several code here such as: 'cancel nicely' (what
we are trying to do), 'cancel hardly' (would just end marking connection
invalid, doing nothing intelligent but ultra-fast).
- the various 'doing' functions would check that and re-act?
- remove the easy from the multi while in do phase, would do only the hard
cancellation, removing the need from doing intelligent things in 'done'.

Regards
Armel
Received on 2006-12-15