Opened 20 months ago

Last modified 19 months ago

#2656 new enhancement remove proactive reconnect code

Reported by: jogger Owned by: zzz
Priority: minor Milestone: undecided
Component: router/transport Version: 0.9.43
Keywords: Cc:
Parent Tickets: Sensitive: no


The proactive reconnect within send(OutNetMessage? msg) can never strike because of the setting of MAX_IDLE. Reason why reconnects should not be done is given there in the comment above. Other conditions in the controlling if clause are also unlikely to strike.


Change History (2)

comment:1 Changed 19 months ago by zzz

Status: newinfoneeded_new

Line 1998

8 events of proactiveReestablish in two days on my medium-speed router, so OP is incorrect.

What 'comment above' is the reason why?

comment:2 Changed 19 months ago by jogger

Status: infoneeded_newnew

I am referring to this comment:

    // We used to have MAX_IDLE_TIME = 5m, but this causes us to drop peers
    // and lose the old introducer tags, causing introduction fails,
    // so we keep the max time long to give the introducer keepalive code
    // in the IntroductionManager a chance to work.
    public static final int EXPIRE_TIMEOUT = 20*60*1000;
    private static final int MAX_IDLE_TIME = EXPIRE_TIMEOUT;

So on your router you must be below 33% max UDP connections. I never run those settings. Usually because of MAX_IDLE_TIME = EXPIRE_TIMEOUT the peer should already have been dropped, but in this case the reconnect code hit after the timeout but before the cleanup timer event did fire. Thus the reconnects you are seeing are random results of kind of a race condition, leaving the OP valid.

Note: See TracTickets for help on using tickets.