Skip to content

Encapsulate message wire encoding into a module #463

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

Merged
merged 3 commits into from
Feb 5, 2020

Conversation

jkczyz
Copy link
Contributor

@jkczyz jkczyz commented Jan 24, 2020

Refactor message wire encoding into a separate module so clients don't have to concern themselves with type numbers and unknown types. Provide wire::Message and wire::MessageType abstractions for encapsulating this behavior. Messages implement the wire::Encode trait which extends Writeable for handling the message type. The module provides read and write convenience methods.

@jkczyz jkczyz requested review from TheBlueMatt and arik-so January 24, 2020 23:55
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Nice. I like this, modulo 1.22 being unhappy. One thing worth considering would be moving the bulk (maybe just not the *MessageHandler traits) from msgs and the new mod here into their own top-level module? Right now most everything is stuffed into ln:: which is kinda awkward.

@jkczyz jkczyz force-pushed the 2020-01-wire-encode branch from ae7ce30 to 298a7d8 Compare January 27, 2020 23:12
Copy link
Contributor Author

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

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

One thing worth considering would be moving the bulk (maybe just not the *MessageHandler traits) from msgs and the new mod here into their own top-level module? Right now most everything is stuffed into ln:: which is kinda awkward.

I'm open to moving things around though I don't have a great sense of how it should be organized/named yet. Perhaps we can hold off until #434 is in to avoid disruption while coming up with a modularization we're happy with.

@jkczyz jkczyz force-pushed the 2020-01-wire-encode branch 2 times, most recently from 651e74d to b8e0be5 Compare January 31, 2020 22:55
@jkczyz
Copy link
Contributor Author

jkczyz commented Jan 31, 2020

Rebased

@jkczyz jkczyz force-pushed the 2020-01-wire-encode branch 2 times, most recently from 89574e0 to 7061109 Compare February 4, 2020 23:49
@jkczyz
Copy link
Contributor Author

jkczyz commented Feb 4, 2020

Fixed a compilation error for Rust 1.22 where I needed to fully scope anything in an std module.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

LGTM, mod the missing & in 1.22.

@jkczyz jkczyz force-pushed the 2020-01-wire-encode branch from 7061109 to f910dac Compare February 5, 2020 06:36
@jkczyz
Copy link
Contributor Author

jkczyz commented Feb 5, 2020

Fixed remaining Rust 1.22 compilation errors.

@jkczyz
Copy link
Contributor Author

jkczyz commented Feb 5, 2020

More Travis failures because the tests don't compile under Rust 1.22.0 (see #471 for details on older releases). Will fix these up now and re-push.

Lightning messages are identified by a 2-byte type when encoded on the
wire. Rather than expecting callers to know message types when sending
messages to peers, have each message implement a trait defining the
message type. Provide an interface for reading and writing messages
as well as a Message enum for matching the decoded message, including
unknown messages.
Create a MessageType abstraction and use it throughout the wire module's
external interfaces. Include an is_even method for clients to determine
how to handle unknown messages.
@jkczyz jkczyz force-pushed the 2020-01-wire-encode branch from f910dac to 0e6b207 Compare February 5, 2020 20:15
@jkczyz
Copy link
Contributor Author

jkczyz commented Feb 5, 2020

Pushed test fixes:

  • Replaced returning Result<> types with () and used unwrap() instead of ?.
  • Replaced to_be_bytes and from_be_bytes from std with custom byte_utils equivalent.
  • Removed use std::convert::TryInto.

@TheBlueMatt TheBlueMatt merged commit 2ec7c77 into lightningdevkit:master Feb 5, 2020
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.

3 participants