Skip to content
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

Extensible Messages #48

Merged
merged 48 commits into from
Mar 17, 2015
Merged

Extensible Messages #48

merged 48 commits into from
Mar 17, 2015

Conversation

braydonf
Copy link
Contributor

  • Messages are now built with a factory that can be customized with an options argument to Messages, for example:

    var messages = new Messages({Block: Block, magicNumber: 0x0b120907});
    var message = messages.GetData.forBlock(inv.hash);
    peer.sendMessage(message);

    Additionally, individual message constructors have been organized into separate files.

  • Peer and Pool now have options defined as an object to avoid needing to pass in "null, null, true" as arguments, for example:

    var pool = new Pool({relay: false, dnsSeed: false, network: Networks.testnet});
  • Adds an Inventory constructor to be shared between several of the message types, separate from the Inventory message.

  • Changes to use BufferWriter instead of needing the "bufferput" dependency.

  • Adds a listen() method to Pool to enable remote peers to be added to the pool upon incoming connections, enables bitcore to bitcore node connectivity.

  • Will disconnect a peer on error (to avoid _connectedPeers having invalid peers).

  • Increases test coverage

@braydonf braydonf changed the title WIP: Feature/extensibility WIP: Extensible Messages Mar 11, 2015
Braydon Fuller added 5 commits March 11, 2015 23:57
- changed options in constructors
- define block and transaction constructors for block and tx messages
- Renamed "Commands" to "builder"
- "Messages.parseMessage" to "Messages.parseBuffer"
- Changed to use private methods for "discardUntilNextMessage" and "buildFromBuffer"
- Cleaned up tests
@coveralls
Copy link

Coverage Status

Coverage increased (+5.9%) to 100.0% when pulling f17bbf5 on braydonf:feature/extensibility into ae93c14 on bitpay:master.

@braydonf braydonf changed the title WIP: Extensible Messages Extensible Messages Mar 16, 2015
};

module.exports = Buffers;

Choose a reason for hiding this comment

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

This seems like a pretty useful function. Should we submit it to the global buffers module https://github.com/substack/node-buffers? I'd be happy to give it a go if that's the right thing to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Possibly, we may not need this dependency either though, since we may only be using push(). Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree, I wanted to take out this dependency as well at some point, don't remember what changed my mind.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Spawned an issue: #52

Copy link
Contributor

Choose a reason for hiding this comment

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

can you unit-test the skip function please?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added test in: braydonf@7cfe6d1

@coveralls
Copy link

Coverage Status

Coverage increased (+5.9%) to 100.0% when pulling 8f2d008 on braydonf:feature/extensibility into ae93c14 on bitpay:master.

* A Peer instance represents a remote bitcoin node and allows to communicate
* with it using the standard messages of the bitcoin p2p protocol.
* A constructor to create Peer instances to send and recieve messages
* using the standard Bitcoin protocol.
*

Choose a reason for hiding this comment

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

How about: "The Peer class implements the Bitcoin peer-to-peer (P2P) network protocol. A Peer instance represents one connection on the Bitcoin network. To create a new peer connection to a remote server, provide the host and port options in the class constructor and then invoke the connect method. Incoming peer connections are handled by the Pool class and its listen method."?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Using "constructor" I think is more descriptive. There is also the option of passing a "socket" in, and "host" and "port" are based on the connected socket.

Choose a reason for hiding this comment

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

You're right that constructor is better here as you had it. There's a typo though *receive. In retrospect my suggestion was really as an update to docs/peer.md class description.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated in: 664ceb2

@eordano
Copy link
Contributor

eordano commented Mar 16, 2015

Amazing work, great!

There are a few nits on the tests names but I'd approve this PR as is. I'll review it more in-deep this afternoon

@braydonf
Copy link
Contributor Author

Two questions:

  1. Should we remove all of the fromObject methods on the message command constructors, since they nolonger seem necesssary ?
  2. Should the magicNumber for messages be stored as a buffer, so it's the same as Network. And writing this is nolonger needed: bitcore.Networks.defaultNetwork.networkMagic.readUInt32LE(0) ?

@eordano
Copy link
Contributor

eordano commented Mar 16, 2015

  1. I wouldn't, it may be useful at some point if we implement .toObject (dunno, maybe somebody interested in sending serialized messages in json?)
  2. Either way it's fine by me. The only verbosity you'd save is the readUINt32LE, right? I'm slightly more concerned about every message doing magicNumber = bitcore.Networks....

@braydonf
Copy link
Contributor Author

  1. Yeah, except that new Message() can be used for those purposes is most (all currently) cases. For JSON it would be fromJSON() that would then call new Message(objectFromJSON).
  2. Only a slight difference, it may be possible to configure Message when required (similar to how the commands are being required with options) so that it magicNumber would be defined at that level instead.

Edit: Took a look at implementing #2 And think the current solution is better.

@coveralls
Copy link

Coverage Status

Coverage increased (+5.9%) to 100.0% when pulling c0e3bdb on braydonf:feature/extensibility into ae93c14 on bitpay:master.

getdata: 'GetData',
headers: 'Headers',
notfound: 'NotFound',
inv: 'Inventory',
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't the message now called InvMessage?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, however it's mapped here with just Inventory. messages.Inventory rather than messages.InvMessage. Should they be the same?

@eordano
Copy link
Contributor

eordano commented Mar 17, 2015

LGTM, let's merge this

*/
InvMessage.forFilteredBlock = function(hash) {
return new InvMessage([Inventory.forFilteredBlock(hash)]);
};
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't like that these 3 methods (forBlock, forFilteredBlock and forTransaction) are repeated in some classes. Why don't you use a generic method builder like: https://github.com/bitpay/bitcore-p2p/blob/master/lib/messages.js#L974 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This could be possible. I left them there so that these constructors could be used standalone (i.e. without the Messages factory), though that isn't a prominent use case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated in: braydonf@34c3846 moved the helpers to builder.

@maraoz
Copy link
Contributor

maraoz commented Mar 17, 2015

Great work in general, left some small comments. Please fix/reply and I'll be happy to merge this :)

@coveralls
Copy link

Coverage Status

Coverage increased (+5.9%) to 100.0% when pulling 34c3846 on braydonf:feature/extensibility into ae93c14 on bitpay:master.

maraoz added a commit that referenced this pull request Mar 17, 2015
@maraoz maraoz merged commit 487b5f0 into bitpay:master Mar 17, 2015
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.

5 participants