pcp
[Top] [All Lists]

Re: Connection timeouts and getaddrinfo

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: Connection timeouts and getaddrinfo
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Wed, 04 May 2016 11:16:28 -0400
Cc: pcp <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <567395411.45186409.1462317980857.JavaMail.zimbra@xxxxxxxxxx>
References: <1046898355.44816857.1462256769212.JavaMail.zimbra@xxxxxxxxxx> <5728D408.8070107@xxxxxxxxxx> <567395411.45186409.1462317980857.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
On 05/03/2016 07:26 PM, Nathan Scott wrote:
Hi Dave,

----- Original Message -----
On 05/03/2016 02:26 AM, Nathan Scott wrote:
[...]
Not sure what the correct behaviour should be here - thoughts?
Seems like its probably not doing what users would expect atm.

The delay is applied during the call __pmSelectWrite(). One thing we
could try would be to open a socket for each address, use the select to
wait on all of them at once, and choose the one that's selected. If the
timeout expires, then we can assume that they all timed out and we will
have applied the timeout once for all of the addresses. I can't think of
another way to apply one timeout while trying all of the addresses.

*nod*

The downside is that PMCD will see several connections, some (most?) of
which will succeed and then be abandoned.
Yeah.  pmcd also has an optional connection-count-limit feature that we
might bump into this way ... but I think those downsides are probably
outweighed by having the timeout applied in a way people would expect.

One other possible pseudo-solution: If the first address times out, try the remaining addresses with a much smaller timeout, since they are likely, but guaranteed to also timeout. This would keep the total timeout time close to what was requested while avoiding the simultaneous connection attempts.

Dave

<Prev in Thread] Current Thread [Next in Thread>