Define all protocol messages

[jmcph4]

Description

BEP 3 specifies several messages that comprise the BitTorrent peer protocol:

0. Choke
1. Unchoke
2. Interested
3. Not Interested
4. Have
5. Bitfield
6. Request
7. Piece
8. Cancel

There are a few implementation strategies that come to mind:

1. Define a struct for each message
   • Naive approach
   • Wasteful
   • Not very DRY
2. Define a single struct for a generic message and then define functions that read and write each message

Neither seem very clean at the moment. Some things to consider:

• C-CONV
• Leveraging serde

Acceptance Criteria

• [ ] Choke messages can be read
• [ ] Choke messages can be written
• [ ] Unchoke messages can be read
• [ ] Unchoke messages can be written
• [ ] Interested messages can be read
• [ ] Interested messages can be written
• [ ] Not Interested messages can be read
• [ ] Not Interested messages can be written
• [ ] Have messages can be read
• [ ] Have messages can be written
• [ ] Bitfield messages can be read
• [ ] Bitfield messages can be written
• [ ] Request messages can be read
• [ ] Request messages can be written
• [ ] Piece messages can be read
• [ ] Piece messages can be written
• [ ] Cancel messages can be read
• [ ] Cancel messages can be written

[jmcph4]

@alecdwm Keen to hear your input from a design perspective.

[jmcph4]

An additional resource which (while unofficial) is very helpful: BitTorrentSpecification.