Opened 5 years ago

Last modified 4 years ago

#1398 new defect

Waiting too long for retrying participating traffic

Reported by: rfree Owned by:
Priority: minor Milestone:
Component: router/general Version: 0.9.15
Keywords: performance peer-selection Cc:
Parent Tickets: Sensitive: no

Description

Related to bug #1397 , #623 - if our peer for any reason is unable to route for nodes that would like to use us (to have them as participating traffic) then it takes 7 days before these nodes will try us again.

So this means even if we had good integration in the meaning that many routers were using our node for participating traffic - then if we would have networking problems or reboot or short downtime we could be back to 0 it seems.

If the time would be lower, we could be back up to high participating traffic very quickly.

If there is no strong reason not to, why not try some exponential backoff with maximum at 7 days and starting with e.g. 1 minute?

It's just 14 more retries compared to current version before getting back to weekly retry.

For comparsion, Freenet darknet retries peers around half-minute.

Subtickets

Change History (2)

comment:1 Changed 5 years ago by rfree

Keywords: participating lag delay backoff time added

comment:2 Changed 4 years ago by str4d

Keywords: performance peer-selection added; participating lag delay backoff time removed
Milestone: 0.9.16
Note: See TracTickets for help on using tickets.