lightning

4152 Commits

55 Branches

107 Tags

38 MiB

Tree: e1dfb1b178

Commit Graph

Author	SHA1	Message	Date
Rusty Russell	72c459dd6c	gossipd: keep reaching struct only when we're actively connecting, and don't retry 1. Lifetime of 'struct reaching' now only while we're actively doing connect. 2. Always free after a single attempt: if it's an important peer, retry on a timer. 3. Have a single response message to master, rather than relying on peer_connected on success and other msgs on failure. 4. If we are actively connecting and we get another command for the same id, just increment the counter The result is much simpler in the master daemon, and much nicer for reconnection: if they say to connect they get an immediate response, rather than waiting for 10 retries. Even if it's an important peer, it fires off another reconnect attempt, unless it's actively connecting now. This removes exponential backoff: that's restored in next patch. It also doesn't handle multiple addresses for a single peer. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	7 years ago
Rusty Russell	36652a3df3	lightningd/peer_control: reorder, move more functions out. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	7 years ago
Rusty Russell	a83ff83328	lightningd/connect_control: routines to control connecting (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>	7 years ago

Author

SHA1

Message

Date

Rusty Russell

72c459dd6c

gossipd: keep reaching struct only when we're actively connecting, and don't retry

1. Lifetime of 'struct reaching' now only while we're actively doing connect.
2. Always free after a single attempt: if it's an important peer, retry
   on a timer.
3. Have a single response message to master, rather than relying on
   peer_connected on success and other msgs on failure.
4. If we are actively connecting and we get another command for the same
   id, just increment the counter

The result is much simpler in the master daemon, and much nicer for
reconnection: if they say to connect they get an immediate response,
rather than waiting for 10 retries.  Even if it's an important peer,
it fires off another reconnect attempt, unless it's actively
connecting now.

This removes exponential backoff: that's restored in next patch.  It
also doesn't handle multiple addresses for a single peer.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

7 years ago

Rusty Russell

36652a3df3

lightningd/peer_control: reorder, move more functions out.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

7 years ago

Rusty Russell

a83ff83328

lightningd/connect_control: routines to control connecting (move from peer_control.c)

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

7 years ago

3 Commits (e1dfb1b178973ba32c3b7a52a163eddf86262e66)