-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Peer backup #8490
base: master
Are you sure you want to change the base?
Peer backup #8490
Changes from 1 commit
52d310c
6d06ced
be3f077
637d6ab
4f70129
3322038
71027b8
5a8be6b
abbb190
8b0bd5b
ccecf4b
63c5f2d
562d40a
46d3a2a
b9d38e5
0b66b3d
9dedf1a
12d4c95
93af069
59f829b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -514,6 +514,10 @@ type Brontide struct { | |
|
||
// log is a peer-specific logging instance. | ||
log btclog.Logger | ||
|
||
// backupData is an in-memory store for data that we store for our | ||
// peers. | ||
backupData lnwire.PeerStorageBlob | ||
} | ||
|
||
// A compile-time check to ensure that Brontide satisfies the lnpeer.Peer interface. | ||
|
@@ -1824,6 +1828,12 @@ out: | |
discStream.AddMsg(msg) | ||
|
||
case *lnwire.PeerStorage: | ||
err = p.handlePeerStorageMessage(msg) | ||
if err != nil { | ||
p.storeError(err) | ||
p.log.Errorf("%v", err) | ||
} | ||
|
||
case *lnwire.PeerStorageRetrieval: | ||
err = p.handlePeerStorageRetrieval() | ||
if err != nil { | ||
|
@@ -4169,6 +4179,42 @@ func (p *Brontide) handleRemovePendingChannel(req *newChannelMsg) { | |
p.addedChannels.Delete(chanID) | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In general, I think a good pattern is to first implement DB things (ie, PeerDataStore) and then to add things that call that interface. Because as is, this commit will actually panic if we receive this message since There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Please no. Implementation should always be last. Interface design first. Use the interface operations in the surrounding code next to validate the ergonomics and structure of the interface design. Finally, implement the interface last. If you go the other way around it causes you to compromise the interface design in favor of the implementation rather than the call-sites. This will cause the quality of the library code in the codebase to atrophy. Intermediate commits not being fully valid implementations is completely fine. If you absolutely do not want to tolerate invalid intermediate commits, you can squash those commits later. Work backwards from the goal, not forwards from the implementation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i do understand & agree with the principle but then I think it is important to make sure that it is not possible to call the interface at runtime yet. Cause that will cause nil panics. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the issue with that in an intermediate commit? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i guess my personal rule is "let's make sure we can revert back any commit without worrying that the commit we are reverting back to actually depends on a future commit to compile/run correctly |
||
|
||
// handlePeerStorageMessage handles `PeerStorage` message, it stores the message | ||
// and sends it back to the peer as an ack. | ||
func (p *Brontide) handlePeerStorageMessage(msg *lnwire.PeerStorage) error { | ||
ellemouton marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// Check if we have the feature to store peer backup enabled. | ||
if !p.LocalFeatures().HasFeature(lnwire.ProvideStorageOptional) { | ||
warning := "received peer storage message but not " + | ||
"advertising required feature bit" | ||
Comment on lines
+4288
to
+4289
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This leaks data to the peer. We should not give indication that we understand the feature here. |
||
|
||
if err := p.SendMessage(false, &lnwire.Warning{ | ||
ChanID: lnwire.ConnectionWideID, | ||
Data: []byte(warning), | ||
}); err != nil { | ||
return err | ||
} | ||
ellemouton marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
p.Disconnect(errors.New(warning)) | ||
|
||
return nil | ||
} | ||
|
||
// If we have no active channels with this peer, we return quickly. | ||
if !p.hasActiveChannels() { | ||
p.log.Tracef("Received peerStorage message from "+ | ||
"peer(%v) with no active channels -- ignoring", | ||
p.String()) | ||
|
||
return nil | ||
} | ||
|
||
p.log.Debugf("handling peerbackup for peer(%s)", p) | ||
|
||
p.backupData = msg.Blob | ||
|
||
return nil | ||
} | ||
|
||
// sendLinkUpdateMsg sends a message that updates the channel to the | ||
// channel's message stream. | ||
func (p *Brontide) sendLinkUpdateMsg(cid lnwire.ChannelID, msg lnwire.Message) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should also have a case here for the storage retrieval message. Since we do know about it but dont allow it. Then we are at least storing a more useful error (since currently it will store the "unknown message" error