>> I have observed one case, where I set 2 minutes timeout and it
>> expired after exactly 9 minutes.
>
> Wow! Very strange behavior.
>
>> Does anybody have a clue what might be the reson for such a behaviour
>> or under what conditions that may happen. ?
>> Is the 9 minutes timeout a special timeout internally defined by
>> libCurl?
>
> No, there's no special 9 minutes timeout and it is expected to use the
> set timeout and nothing else.

Some further tests regarding the issue were made and here are the
findings so far.
The effect with the 9 minutes timeout instead of the configured 2
minutes timeout appearead reproducible in case
a) HTTPS (and therefore SSL) is used and
b) In case the physical layer of the network connection is removed by
hand (e.g. remove the antenna in our case; a wireless connection is
used) _during_ the SSL handshake phase.

The libCurl debug function prints out the following information: "SSL
connection timeout" after 9 minutes.

I have not dived into the problem further until know. So, here are my
conclusions / questions:

1) Is the configured easy handle timeout of 2 minutes also relevant for
the OpenSSL library, or does OpenSSL has its own timeouts for the
handshake phase, which are not under control of libCurl?
2) I looked for the "SSL connection timeout" string and found it in the
file ssluse.c. Do you have a clue what is going wrong at the respective
places ? I'll try to debug the issue on QNX or Win32. Can you give me
your thoughts of what might goes wrong here and were to look best in
order to track the problem down ?

Used OS is QNX 6.3.2 and libcurl 7.16.3 is used. OpenSSL is 0.9.8e (I am
not quite sure about the minor number at the moment)

Thanks and regards

   Stefan

>
>> Does the correct working of the timeout feature somehow depend on the
>> FD_SETSIZE configuration?
>
> No.
>
>> The OS is QNX 6.3.2 and libcurl 7.16.3 is used.
>
> Can you try the same magic case on another operating system and/or
> libcurl release and see if it still occurs?
>
Received on 2008-04-09