Fix improve transport setup logic issue #818
Conversation
…g instead after that
|
|
| @@ -192,7 +192,7 @@ func (tm *Manager) initTransports(ctx context.Context) { | |||
| tpID = entry.Entry.ID | |||
| ) | |||
| isInitiator := tm.n.LocalPK() == entry.Entry.Edges[0] | |||
| if _, err := tm.saveTransport(remote, isInitiator, tpType, entry.Entry.Label); err != nil { | |||
| if _, err := tm.saveTransport(ctx, remote, isInitiator, tpType, entry.Entry.Label); err != nil { | |||
There was a problem hiding this comment.
if I understand correctly, you moved dialing part from SaveTransport to saveTransport. The naming is probably not the best, but SaveTransport is called via rpc and api, and is essentially "I want to add new transport to there".
saveTransport is actually "save this transport and run it". Here it is saved when a transport entry is obtained from transport discovery. Original implementation includes measures to prevent both ends of transport of dialing each other (initially by using PK value and recently by using initiator logic). Currently, it seems that both ends can get into dialing state easily. I'm not sure if this won't introduce weird connectivity issues when a visor comes online with a number of transports for him in TD, while other ends of them are also online.
Can you please elaborate on this?
There was a problem hiding this comment.
The situation that you explain is same as that I have a visor with a served transport (for example a VPN as dmsg), and get offline, and get back online after two hours for example. For now in initTransport, that called when visor get back online, the Serve run again, but without dialing discovery, that means transport(s) added to visor both in online or offline status.
Did you run
make format && make check?Fixes #771
Changes:
How to test this PR: