net: Add and document network messages in protocol.h

- 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.

1 files changed, 159 insertions, 0 deletions

diff --git a/src/protocol.h b/src/protocol.h
index 50aeaf44ba..b84c78baca 100644
--- a/src/protocol.h
+++ b/src/protocol.h
@@ -65,6 +65,165 @@ public:
     unsigned int nChecksum;
 };
 
+/**
+ * Bitcoin protocol message types. When adding new message types, don't forget
+ * to update allNetMessageTypes in protocol.cpp.
+ */
+namespace NetMsgType {
+
+/**
+ * The version message provides information about the transmitting node to the
+ * receiving node at the beginning of a connection.
+ * @see https://bitcoin.org/en/developer-reference#version
+ */
+extern const char *VERSION;
+/**
+ * The verack message acknowledges a previously-received version message,
+ * informing the connecting node that it can begin to send other messages.
+ * @see https://bitcoin.org/en/developer-reference#verack
+ */
+extern const char *VERACK;
+/**
+ * The addr (IP address) message relays connection information for peers on the
+ * network.
+ * @see https://bitcoin.org/en/developer-reference#addr
+ */
+extern const char *ADDR;
+/**
+ * The inv message (inventory message) transmits one or more inventories of
+ * objects known to the transmitting peer.
+ * @see https://bitcoin.org/en/developer-reference#inv
+ */
+extern const char *INV;
+/**
+ * The getdata message requests one or more data objects from another node.
+ * @see https://bitcoin.org/en/developer-reference#getdata
+ */
+extern const char *GETDATA;
+/**
+ * The merkleblock message is a reply to a getdata message which requested a
+ * block using the inventory type MSG_MERKLEBLOCK.
+ * @since protocol version 70001 as described by BIP37.
+ * @see https://bitcoin.org/en/developer-reference#merkleblock
+ */
+extern const char *MERKLEBLOCK;
+/**
+ * The getblocks message requests an inv message that provides block header
+ * hashes starting from a particular point in the block chain.
+ * @see https://bitcoin.org/en/developer-reference#getblocks
+ */
+extern const char *GETBLOCKS;
+/**
+ * The getheaders message requests a headers message that provides block
+ * headers starting from a particular point in the block chain.
+ * @since protocol version 31800.
+ * @see https://bitcoin.org/en/developer-reference#getheaders
+ */
+extern const char *GETHEADERS;
+/**
+ * The tx message transmits a single transaction.
+ * @see https://bitcoin.org/en/developer-reference#tx
+ */
+extern const char *TX;
+/**
+ * The headers message sends one or more block headers to a node which
+ * previously requested certain headers with a getheaders message.
+ * @since protocol version 31800.
+ * @see https://bitcoin.org/en/developer-reference#headers
+ */
+extern const char *HEADERS;
+/**
+ * The block message transmits a single serialized block.
+ * @see https://bitcoin.org/en/developer-reference#block
+ */
+extern const char *BLOCK;
+/**
+ * The getaddr message requests an addr message from the receiving node,
+ * preferably one with lots of IP addresses of other receiving nodes.
+ * @see https://bitcoin.org/en/developer-reference#getaddr
+ */
+extern const char *GETADDR;
+/**
+ * The mempool message requests the TXIDs of transactions that the receiving
+ * node has verified as valid but which have not yet appeared in a block.
+ * @since protocol version 60002.
+ * @see https://bitcoin.org/en/developer-reference#mempool
+ */
+extern const char *MEMPOOL;
+/**
+ * The ping message is sent periodically to help confirm that the receiving
+ * peer is still connected.
+ * @see https://bitcoin.org/en/developer-reference#ping
+ */
+extern const char *PING;
+/**
+ * The pong message replies to a ping message, proving to the pinging node that
+ * the ponging node is still alive.
+ * @since protocol version 60001 as described by BIP31.
+ * @see https://bitcoin.org/en/developer-reference#pong
+ */
+extern const char *PONG;
+/**
+ * The alert message warns nodes of problems that may affect them or the rest
+ * of the network.
+ * @since protocol version 311.
+ * @see https://bitcoin.org/en/developer-reference#alert
+ */
+extern const char *ALERT;
+/**
+ * The notfound message is a reply to a getdata message which requested an
+ * object the receiving node does not have available for relay.
+ * @ince protocol version 70001.
+ * @see https://bitcoin.org/en/developer-reference#notfound
+ */
+extern const char *NOTFOUND;
+/**
+ * The filterload message tells the receiving peer to filter all relayed
+ * transactions and requested merkle blocks through the provided filter.
+ * @since protocol version 70001 as described by BIP37.
+ *   Only available with service bit NODE_BLOOM since protocol version
+ *   70011 as described by BIP111.
+ * @see https://bitcoin.org/en/developer-reference#filterload
+ */
+extern const char *FILTERLOAD;
+/**
+ * The filteradd message tells the receiving peer to add a single element to a
+ * previously-set bloom filter, such as a new public key.
+ * @since protocol version 70001 as described by BIP37.
+ *   Only available with service bit NODE_BLOOM since protocol version
+ *   70011 as described by BIP111.
+ * @see https://bitcoin.org/en/developer-reference#filteradd
+ */
+extern const char *FILTERADD;
+/**
+ * The filterclear message tells the receiving peer to remove a previously-set
+ * bloom filter.
+ * @since protocol version 70001 as described by BIP37.
+ *   Only available with service bit NODE_BLOOM since protocol version
+ *   70011 as described by BIP111.
+ * @see https://bitcoin.org/en/developer-reference#filterclear
+ */
+extern const char *FILTERCLEAR;
+/**
+ * The reject message informs the receiving node that one of its previous
+ * messages has been rejected.
+ * @since protocol version 70002 as described by BIP61.
+ * @see https://bitcoin.org/en/developer-reference#reject
+ */
+extern const char *REJECT;
+/**
+ * Indicates that a node prefers to receive new block announcements via a
+ * "headers" message rather than an "inv".
+ * @since protocol version 70012 as described by BIP130.
+ * @see https://bitcoin.org/en/developer-reference#sendheaders
+ */
+extern const char *SENDHEADERS;
+
+};
+
+/* Get a vector of all valid message types (see above) */
+const std::vector<std::string> &getAllNetMessageTypes();
+
 /** nServices flags */
 enum {
     // NODE_NETWORK means that the node is capable of serving the block chain. It is currently