Add a skeleton enum for network messages.

zebra-network/src/lib.rs

@@ -1,7 +1,5 @@
-#[cfg(test)]
+//! Networking code for Zebra.
-mod tests {
+
-    #[test]
+#[deny(missing_docs)]
-    fn it_works() {
+
-        assert_eq!(2 + 2, 4);
+pub mod message;
-    }
-}

zebra-network/src/message.rs

@@ -0,0 +1,46 @@
+//! Definitions of network messages.
+
+/// A Bitcoin-like network message for the Zcash protocol.
+///
+/// The Zcash network protocol is mostly inherited from Bitcoin, and a list of
+/// Bitcoin network messages can be found [on the Bitcoin
+/// wiki][btc_wiki_protocol].
+///
+/// That page describes the wire format of the messages, while this enum stores
+/// an internal representation. The internal representation is unlinked from the
+/// wire format, and the translation between the two happens only during
+/// serialization and deserialization. For instance, Bitcoin identifies messages
+/// by a 12-byte ascii command string; we consider this a serialization detail
+/// and use the enum discriminant instead. (As a side benefit, this also means
+/// that we have a clearly-defined validation boundary for network messages
+/// during serialization).
+///
+/// [btc_wiki_protocol]: https://en.bitcoin.it/wiki/Protocol_documentation
+pub enum Message {
+    /// A `version` message.
+    ///
+    /// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#version)
+    Version {/* fields */},
+    /// A `verack` message.
+    ///
+    /// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#verack)
+    Verack {/* fields */},
+    /// A `ping` message.
+    ///
+    /// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#ping)
+    Ping {
+        /// A random nonce.
+        nonce: u64,
+    },
+    /// A `pong` message.
+    ///
+    /// [Bitcoin reference](https://en.bitcoin.it/wiki/Protocol_documentation#pong)
+    Pong {
+        /// The nonce from the `Ping` message this was in response to.
+        nonce: u64,
+    },
+}
+
+// Q: how do we want to implement serialization, exactly? do we want to have
+// something generic over stdlib Read and Write traits, or over async versions
+// of those traits?