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

net: Add and document network messages in protocol.h #7181

Merged
merged 1 commit into from
Dec 11, 2015

Conversation

laanwj
Copy link
Member

@laanwj laanwj commented Dec 7, 2015

  • Avoids string typos (by making the compiler check).
  • Makes it easier to grep for handling/generation of a certain message type.
  • Refer directly to documentation by following the symbol in IDE or doxygen.
  • Make sure we have an overview of all handled/emitted messages, for functionality like log bytes recv/sent per command #6589.

@harding I've used your descriptions of the message types, hope you don't mind :)

Edit: sendheaders is not yet documented in the developer docs, this is tracked here: bitcoin-dot-org/Bitcoin.org#1153

@laanwj
Copy link
Member Author

laanwj commented Dec 7, 2015

@jonasschnelli second commit moves your logAllowIncomingMsgCmds to protocol.cpp, I think this makes sense to have everything related to message types together.

@laanwj laanwj force-pushed the 2015_12_network_messages branch 2 times, most recently from 2746d63 to dbbdb27 Compare December 7, 2015 15:54
@@ -140,3 +172,9 @@ std::string CInv::ToString() const
{
return strprintf("%s %s", GetCommand(), hash.ToString());
}

Copy link

Choose a reason for hiding this comment

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

Is this double newline supposed to be here? I noticed it earlier in the file too (unrelated to this change).

Copy link
Member Author

Choose a reason for hiding this comment

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

No ,not on purpose, will remove it

@jonasschnelli
Copy link
Contributor

Careful Code Review ACK.
Nice. This change was long overdue!

@GIJensen
Copy link

GIJensen commented Dec 7, 2015

utACK, I was thinking about how we needed this today!

@paveljanik
Copy link
Contributor

ACK

@jgarzik
Copy link
Contributor

jgarzik commented Dec 7, 2015

ut ACK

Cosmetic nit: It would be nice to break up allNetMessageTypes[] into one-per-line in the source code, permitting a more simple future patch of

 + NET_MSG_MYNEWMSG,

versus

 - NET_MSG_A, NET_MSG_B, NET_MSG_C, NET_MSG_D
 + NET_MSG_A, NET_MSG_B, NET_MSG_MYNEWMSG, NET_MSG_C, NET_MSG_D

for future patch readability and simplicity.

@pstratem
Copy link
Contributor

pstratem commented Dec 7, 2015

er... why?

@harding
Copy link
Contributor

harding commented Dec 8, 2015

Note, PR bitcoin-dot-org/Bitcoin.org#1154 has been opened in the Bitcoin.org repository to add brief sendheaders documentation at the URL referenced in this PR. Thanks!

NET_MSG_NOTFOUND, NET_MSG_FILTERLOAD, NET_MSG_FILTERADD, NET_MSG_FILTERCLEAR, NET_MSG_REJECT,
NET_MSG_SENDHEADERS
};
const static std::vector<std::string> allNetMessageTypesVec(allNetMessageTypes, allNetMessageTypes+ARRAYLEN(allNetMessageTypes));
Copy link
Contributor

Choose a reason for hiding this comment

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

1 day, initializer lists.

@dcousens
Copy link
Contributor

dcousens commented Dec 8, 2015

utACK f5b1d97 (and verified consistent constant usage).

Agreed this will make grepping way easier, plus it documents each command with clear entry points for new features etc.

@laanwj
Copy link
Member Author

laanwj commented Dec 8, 2015

er... why?

Is there anything unclear from the opening post?
If you really want to know the secret reason is: "makes maintenance for me easier".

Cosmetic nit: It would be nice to break up allNetMessageTypes[] into one-per-line in the source code, permitting a more simple future patch of

Makes sense.

@laanwj
Copy link
Member Author

laanwj commented Dec 8, 2015

Rebased and squashed after #7180

@laanwj
Copy link
Member Author

laanwj commented Dec 8, 2015

@theuni Hope this doesn't collide with your P2P work?

@laanwj
Copy link
Member Author

laanwj commented Dec 8, 2015

Any opinion on putting the constants in a namespace instead of NET_MSG_ prefix?
NET_MSG_SENDHEADERS would become e.g. NetMsgType::SENDHEADERS. This is syntactically more in line with C++11 strongly typed enumerations.
(could make it an actual enumeration at some point provided something else does conversion from/to string, which would make comparison/switching easier, but that's not the goal here)

@paveljanik
Copy link
Contributor

+1!

@jonasschnelli
Copy link
Contributor

Agree with using a namespace instead of the NET_MSG_ prefix.

@pstratem
Copy link
Contributor

pstratem commented Dec 8, 2015

@laanwj hmm ok

utACK 399551f2c246844f8a8c4994142c6e04bf283778

@jgarzik
Copy link
Contributor

jgarzik commented Dec 9, 2015

@laanwj Yes - we should start using namespaces. IMO first step is Bitcoin:: and second step is Net:: under that.

@dcousens
Copy link
Contributor

dcousens commented Dec 9, 2015

reACK 399551f

- Avoids string typos (by making the compiler check)
- Makes it easier to grep for handling/generation of a certain message type
- Refer directly to documentation by following the symbol in IDE
- Move list of valid message types to protocol.cpp:
    protocol.cpp is a more appropriate place for this, and having
    the array there makes it easier to keep things consistent.
@morcos
Copy link
Member

morcos commented Dec 10, 2015

utACK. Thanks!

@laanwj laanwj merged commit 9bbe71b into bitcoin:master Dec 11, 2015
laanwj added a commit that referenced this pull request Dec 11, 2015
9bbe71b net: Add and document network messages in protocol.h (Wladimir J. van der Laan)
laanwj added a commit that referenced this pull request Dec 11, 2015
- Avoids string typos (by making the compiler check)
- Makes it easier to grep for handling/generation of a certain message type
- Refer directly to documentation by following the symbol in IDE
- Move list of valid message types to protocol.cpp:
    protocol.cpp is a more appropriate place for this, and having
    the array there makes it easier to keep things consistent.

Github-Pull: #7181
Rebased-From: 9bbe71b
UdjinM6 pushed a commit to dashpay/dash that referenced this pull request Jun 29, 2017
…itcoin#7181: enable per-command byte counters in `CNode` (#1496)

* log bytes recv/sent per command

* net: Account for `sendheaders` `verack` messages

Looks like these were forgotten in bitcoin#6589.

* Backport remaining part of Bitcoin PR bitcoin#7181.

Most of this PR is already merged, but a small part remaining
that makes per-command byte counts in CNode working.

Signed-off-by: Oleg Girko <ol@infoserver.lv>
spencerlievens added a commit to duality-solutions/Dynamic that referenced this pull request Nov 12, 2017
* enable per-command byte counters in  (#1496)

* log bytes recv/sent per command

* net: Account for   messages

Looks like these were forgotten in #6589.

* Backport remaining part of Bitcoin PR bitcoin/bitcoin#7181.

Most of this PR is already merged, but a small part remaining
that makes per-command byte counts in CNode working.

Signed-off-by: Oleg Girko <ol@infoserver.lv>
AmirolAhmad pushed a commit to AmirolAhmad/gobytes-test that referenced this pull request Dec 11, 2017
… per-command byte counters in `CNode` (#1496)

* log bytes recv/sent per command

* net: Account for `sendheaders` `verack` messages

Looks like these were forgotten in #6589.

* Backport remaining part of Bitcoin PR bitcoin/bitcoin#7181.

Most of this PR is already merged, but a small part remaining
that makes per-command byte counts in CNode working.

Signed-off-by: Oleg Girko <ol@infoserver.lv>
AmirolAhmad pushed a commit to AmirolAhmad/gobytes-test that referenced this pull request Dec 12, 2017
… per-command byte counters in `CNode` (#1496)

* log bytes recv/sent per command

* net: Account for `sendheaders` `verack` messages

Looks like these were forgotten in #6589.

* Backport remaining part of Bitcoin PR bitcoin/bitcoin#7181.

Most of this PR is already merged, but a small part remaining
that makes per-command byte counts in CNode working.

Signed-off-by: Oleg Girko <ol@infoserver.lv>
furszy added a commit to PIVX-Project/PIVX that referenced this pull request May 8, 2020
26b1d9e Apply clang-format (Fuzzbawls)
f12f540 Add and document layer 2 network messages to protocol.h (Fuzzbawls)
7a176ed net: Add and document network messages in protocol.h (Wladimir J. van der Laan)

Pull request description:

  Ported from bitcoin#7181 with layer 2 messages in a followup commit, then ran both commits through `clang-format-diff.py`

  > - Avoids string typos (by making the compiler check)
  > - Makes it easier to grep for handling/generation of a certain message type
  > - Refer directly to documentation by following the symbol in IDE
  > - Move list of valid message types to protocol.cpp:
  >     protocol.cpp is a more appropriate place for this, and having
  >     the array there makes it easier to keep things consistent.

ACKs for top commit:
  random-zebra:
    Very nice. utACK 26b1d9e
  furszy:
    ACK 26b1d9e

Tree-SHA512: a1d08ffb940a66b03856779180e00c212234adc8af3f175e67f694b040e426f35de2cfe6725a3bcdcb606c0468cc33e17e1882a0e2d7f657eebfdb273f0f523c
zkbot added a commit to zcash/zcash that referenced this pull request Feb 17, 2021
Use SipHash for node eviction

Backport of bitcoin/bitcoin#8173

Commits are listed in stack order.

- pick bitcoin/bitcoin@eebc232187
- pick bitcoin/bitcoin@888483098e
- pick bitcoin/bitcoin@c31b24f745
- pick bitcoin/bitcoin@9bf156bb9e
- pick bitcoin/bitcoin@053930ffc4
   - missing bitcoin/bitcoin#5697 (not a candidate for direct inclusion), using pieces directly
   - conflicts with #1258 which it removes part of (this is ok)
      - ignore bitcoin/bitcoin#6374
      - requires bitcoin/bitcoin#7906, or at least bitcoin/bitcoin@cca221fd21
         - pick bitcoin/bitcoin@cca221fd21
   - conflicts with bitcoin/bitcoin#7181, not needed until later if at all
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants