?
The initial message between peers. It contains some info about the sender, and a list of the files needed. If the receiver doesn’t have the files, he will close the connection, but if he does, he will send back a similar message for confirmation.
The message a receiver sends back after the initial handshake. It’s main use is to tell the sender which pieces the receiver has. This happens through two fields: Have and Bitfield.This field indicates, through an index, that the peer has that piece. Ex: If the peer has pieces 1 and 3, he would send back two messages with the payload being 1 and 3 (the piece index), respectively.
Bitfield is basically the same as have, but instead of beign a single message indicating the piece index, it is a single string that shows all pieces, and the current have status (1 for have, 0 for not have). Ex: Taking the previous example, assume that the torrent has a total of 6 pieces, and that the peer has the pieces at index 1 and 3. In that case, the bitfield string/message would be the following: 010100 A 6-character string, formed by all zeroes except for indexes 1 and 3.
It is possible to receive both have and bitfield messages. In that case, they should be combined to get the full list DISCLAIMER: For now, not sure how exactly it works when both messages are received, but my current guess would be to just check the length of the bitfield, and the indexes of the have messages, and declare the number of pieces by the highest number.
Usually, the confirmation message will be the first message received from a peer. But there are other kinds of messages, related to what pieces one has and the other wants, and if they will share those pieces or not. Those are the choke/unchoke, and interested/not interested messages.
The interested message indicates that you want the pieces the peer has, and not interested that you don’t want/need them.
The choke message indicates that the peer does not want to share with you; the unchoke is the opposite. The sender always starts choked and not interested, so the common course of action would be to send a interested message and receive the unchoke, then move on to the request message. But it is also possible that the receiver does not want to share, and sends back another choke message. In that case, the connection to that peer should be dropped.
Message containing the index of the piece the sender wants. **Will re-write later**Contains the actual piece/bytes requested.