On Mon, Jul 4, 2016 at 5:01 PM, Arne Schwabe <a...@rfc2549.org> wrote:
> > Or do you have tcp-client in mind? In case of tcp-client, before this > > patch, "--connect-retry 0" will hammer the server with repeated > > retries. That will be avoided as max sec defaults to 300 sec, unless > > the user specifies "--connect-retry 0 0". Shall we require that the > > second arg to connect-retry should be greater than some minimum, say, at > > least 10 sec? > > No, the TCP-SERVER line there is for p2p mode but with tcp-server. In > p2p mode with p2p the code will also execute that socket-restart code > after the other side will disconnect. In the p2p case the tcp server will just do a SIGUSR1 restart and wait for the client, isn't it -- at least that's what my tests showed on Linux. With "--connect-retry 0", the pause time for tcp-server before restart will be "1, 1, 1, 1, 1, 2, 4, 8 .." seconds until it reaches the max value. If I move the "if for TCP_SERVER" to below the exponential backoff, the server restart pause interval will stay fixed at 1 sec with no backoff. Is that what is preferred? Or am I missing something? The only issue I see is that the interval for tcp-server will get reset to 0 after 5 retries if "--connect-retry 0 0" is used. This is a general issue that is even worse for the tcp-client which will repeatedly try to reconnect with no pause. Both situations may be fixed by requiring the max interval to be > 0 as I mentioned in my previous email. Selva
