Opened 6 weeks ago

Last modified 6 weeks ago

#2377 new defect

Start i2ptunnel from router state machine, or reduce delay

Reported by: zzz Owned by:
Priority: minor Milestone: 0.9.39
Component: router/general Version: 0.9.37
Keywords: Cc: zab
Parent Tickets:

Description

Clients are loaded very early in the startup process (before the router is running at all) in Router.runRouter() which runs StartupJob? which runs LoadClientAppsJob?. We want to load clients.config very early as it fires off the router console.

i2ptunnel is started from clients.config with a delay that's coded in clients.config, or default 2 minutes. 4 years ago we added a delay of 35 seconds in the file, so new installs since then have a shorter delay.

That checkin says:

Router: Add startup/shutdown state machine
ClientAppConfig: Start i2ptunnel sooner
  Since BuildRequestor won't use a zero-hop exploratory as a paired tunnel
  for client builds, it's now safe to start client tunnels
  before the expl. tunnels are ready. This will save up to 90 seconds.

If correct, this allows us to start i2ptunnel even earlier. However, there may be other side effects of starting i2ptunnel immediately. For example, client tunnel builds will eventually timeout if the router has trouble building exploratory tunnels.

We could special-case the i2ptunnel delay setting in LoadClientAppsJob? to ignore the value in the file, so all users would benefit from increased startup. We could additionally special-case it to start it from the router state machine when it gets to RUNNING, although this could mean a prolonged delay if the router can't build tunnels. Note that before i2ptunnel is started, the UI for it is unavailable, which could be problematic.

For starters, will test a value of 5 seconds and see how it goes. A very slow platform such as RPi needs to be a part of the testing.

Subtickets (add)

Change History (1)

comment:1 Changed 6 weeks ago by zab

How about adding a boolean property to each client in clients.config whether it requires the state machine to be in RUNNING state before it can start? That way there's no need to add callbacks from the state machine and the LoadClientAppsJob can poll periodically, should be a smaller change.

Note: See TracTickets for help on using tickets.