curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: unexpected code 35 (if tcp listen backlog is full)

From: Michael Kilburn via curl-library <curl-library_at_cool.haxx.se>
Date: Sun, 14 Jan 2018 04:47:30 -0600

On Sun, Jan 14, 2018 at 4:14 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Sun, 14 Jan 2018, Michael Kilburn via curl-library wrote:
>
>> But I could be wrong -- I vaguely remember reading about some
>> optimization where connection was "opening" immediately,
>>
>
> TFO (TCP Fast Open) allows for data to be sent already in the handshake,
> but unless you ask for that, libcurl won't try to use TFO so that's not the
> case here.

When you get a TLS error returned, we can assume libcurl did a successful
> TCP connection handshake and continued to do the TLS negotiation. The
> VERBOSE output from libcurl will probably also confirm this.

In this case it must be a bug of some sorts -- how overflown TCP backlog
(which plays role only during TCP handshake) can cause any TLS-related
problems on already established connection? Hmm... On second thought this:
http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html
 suggests it is possible -- if accept queue is full, ACK gets discarded
while from client perspective connection is established and it will start
sending data (initiating TLS handshake). And eventual RST from server
(because it could not acknowledge resent ACKs due to full accept queue)
will cause connection drop while libcurl TLS logic waits for response. Do
you think this is what happens? Can code 35 be returned in this situation?

I'll try to look into this again on Monday.

> Yes. Typically you'd have a multi handle which shares the connection cache.
>>>
>>
>> Hmm... I need to look into this. Something tells me that having cache of
>> easy handles (protected by mutex) isn't the most efficient solution either.
>>
>
> It mostly depends on what the alternative is. In a lot of cases it is
> certainly the moste efficient solution, like when the alternative means
> setting up an entirely new TLS connection instead of re-using one and
> "wasting" some microseconds on a mutex.
>
> But we only provide the means, it is up to every user to deem what is the
> best way for their use case.

If I am to use my own cache of easy handles -- how it is going to work wrt
TLS? Afair, TLS handshake needs to be renewed/renegotiated on regular basis
-- what if my handle wasn't used for 10 mins? 2 hours?

-- 
Regards,
Michael.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-01-14