Skip to content

routing: moved routing package inside lnd#70

Merged
Roasbeef merged 1 commit into
lightningnetwork:masterfrom
BitfuryLightning:routing-move-tools
Nov 24, 2016
Merged

routing: moved routing package inside lnd#70
Roasbeef merged 1 commit into
lightningnetwork:masterfrom
BitfuryLightning:routing-move-tools

Conversation

@BitfuryLightning
Copy link
Copy Markdown
Contributor

@BitfuryLightning BitfuryLightning commented Nov 2, 2016

Moved routing tools inside lnd. Changed internal type of graph.ID
from string to [33]byte.

Comment thread routing/rt/graph/graph.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't clear to me why this function is needed. The function below NewID seems to be sufficient, as within our graph vertexes are always public keys serialized in compressed format.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NewIDDebug deleted.

Comment thread lnwire/lnwire.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is graph.ID converted to a string before encoding the element? It would

I don't think that graph.ID should be converted to a string before encoding the element. Instead the relevant fields should be publicly exposed, then serialized individually one level up (within the Encode/Decode) functions. The encoding should be as efficient as possible, so a raw binary encoding of the struct should be used.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted. lnwire decoupled from graph.

Comment thread lnwire/lnwire.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar comments apply to the handling of the case statements from here to the comment above.

Most of the logic that's currently within the case statement of each of the routing related structs should be within the Encode/Decode methods of their respective lnwire structs.

Comment thread lnwire/lnwire.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error is being ignored here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted. lnwire decoupled from graph.

Comment thread lnwire/lnwire.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error is being ignored here.

Copy link
Copy Markdown
Contributor Author

@BitfuryLightning BitfuryLightning Nov 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted. lnwire decoupled from graph

Comment thread routing/rt/rt.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This init function is no longer needed as we now have (after my review comments are addressed) manual serialization of the relevant objects in the lnwire package.

Comment thread routing/rt/rt.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These gob functions are no longer needed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted.

Comment thread routing/rt/rt.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this function is needed since the graph itself is currently publicly exported.

Comment thread routing/rt/visualizer/config.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All publicly exported variables in this package are missing godoc-style comments. Also, I think this package should be converted to an internal golang package.

Comment thread routing/rt/visualizer/visualizer.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The errors here shouldn't be ignored. Also I think many of the functions should not be publicly exported. Instead, only the necessary public entrance points need to be exposed.

Copy link
Copy Markdown
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM ✨

Thanks for all the hardwork on this PR! This'll serve as a fine basis for routing within the daemon.

I'll get this merged as soon as the merge conflicts are resolved on this branch.

Use [33]byte for graph vertex representation.
Delete unneeded stuff:
1. DeepEqual for graph comparison
2. EdgePath
3. 2-thread BFS
4. Table transfer messages and neighborhood radius
5. Beacons

Refactor:
1. Change ID to Vertex
2. Test use table driven approach
3. Add comments
4. Make graph internal representation private
5. Use wire.OutPoint as  EdgeId
6. Decouple routing messages from routing implementation
7. Delete Async methods
8. Delete unneeded channels and priority buffer from manager
9. Delete unneeded interfaces in internal graph realisation
10. Renamed ID to Vertex
@BitfuryLightning
Copy link
Copy Markdown
Contributor Author

I've rebased and squashed commits. Is it bug in the tests or in the code?
On my local, machine it sometimes passes, sometimes fails.

@Roasbeef
Copy link
Copy Markdown
Member

There's some occasional negative interaction between the integration tests that I haven't yet quite pinned down which causes the occasional flakiness you're seeing. I have a few more items on my personal TODO list, but will hopefully eliminate the flakiness in the next few days.

@Roasbeef Roasbeef merged commit 327768f into lightningnetwork:master Nov 24, 2016
mrfelton pushed a commit to LN-Zap/lnd that referenced this pull request May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants