dead / inactive transports in TPD ; implement periodic re-registration interval for transports & check of transport status in TPD

[0pcom]

The current TPD monitor implementation only removes transports from TPD if they are not found to be usable by the tpd monitor.

The issue is, after the transports have been removed from TPD, they are still registered on the visor.

This creates a situation where visors have transports that don't exist in TPD and which may or may not be usable.

For instance ; a public visor was started. The TPD monitor was removing good transports from the transport discovery. The public visor was restarted after stopping TPD monitor. The same number of transports did not reappear for the public visor.

It became apparent that remote visors which had previously registered these transports to the public visor still had these transports registered (verify this is actually the case) and either for that reason or another reason, did not attempt to re-create them or attempt to reconnect to the same public visor.

Temporary workaround for this situation was to restart the public visor with a new key, so that visors which had previously connected would connect again to the new key.

proposed solution

• re-registration interval for transports in TPD
• report bandwidth and latency for transports to TPD upon re-registration or removal of transport
• visor should check the transports it has registered against those in tpd ; re-create or re-register the transports which are not present in TPD ; if it's not possible to re-create the transport then delete its local entry for the visor.

[0pcom]

i have two transports shown on my local visor

$ skywire-cli visor pk
0323272a60895f56aad82cb767fb5c413807adcf7c9fb0578b1b1c5807c7f29d4c
[user@linux ~]$ skywire-cli visor tp ls
type      id                                       remote_pk                                                              mode        label
sudph     247984d4-4a1a-0eda-a67c-9e69bf0fb169     0382406ebecec832a1c27dece7cf58425a1c98753c7b3be8428d4414eada0986ac     regular     automatic
dmsg      c6e0e33b-3ffb-0de4-ae5e-27e85caaace1     03d0c4a4df6fd1db6f9329a8bbfeb6879a171d554afe9bfbdcac5cb9c34f62a2d6     regular     automatic

However, according to TPD (skywire cli rtree) there are lots of transports ; more to my visor than to any other

Also, there are many transports shown for visors which are offline