Developers.WhereEachJobIsDone
No matter how they are designed and coded, all peer-to-peer programs have to do the same set of jobs. Some examples of these jobs are listening on a socket, connecting a socket, negotiating the handshake, and dealing with each kind of packet.
Shareaza's current design doesn't pull each of these jobs into one place in the code. The jobs are spread throughout the object-oriented classes of Shareaza. This page is a lookup table. Given a certain job, it will tell you where to find code that does it.
Listening on a socket
A peer-to-peer program has to setup a socket and listen on it. Then, if the computer is externally contactable on the Internet, the socket will get contacted by new remote computers.
- CHandshakes has a member variable, m_hSocket. This is the one listening socket for Shareaza. The method Listen sets it up.
Connecting a socket
Peer-to-peer programs use TCP sockets to send and receive data with a connected remote computer.
- CConnection has a member variable, m_hSocket. This is the TCP connection socket. When Shareaza runs, it makes an object that inherits from CConnection for each connected remote computer. The methods OnRead and OnWrite transfer data through the socket.
Compressing and decompressing the data stream
The popular zlib library compresses the data stream on a socket, making information flow faster.
- CNeighbour has methods OnRead and OnWrite which use the zlib library directly to compress and decompress the data stream infront of the socket.
- The class CZLib compresses data, but can't do stream compression. It isn't used here.
Negotiating the handshake
The first data two connected computers send to each other are ASCII characters that make up lines of text. They describe what each computer wants, and what its abilities are. A peer-to-peer program has to read and respond to these handshake headers, keep track of what the remote computer has said, and determine if it should keep the connection going.
- CHandshake::OnRead has code that looks at the first 7 bytes a newly connected remote computer sends us, and determines what the computer wants.
- CShakeNeighbour defines member variables like m_bDeflateAccept that are TRUE if the remote computer has told us a certain handshake header. Methods in CShakeNeigbour like SendMinimalHeaders and OnHeaderLine read and respond to headers.
- CConnection has some methods that deal with headers, like ReadHeaders, OnHeaderLine, and SendMyAddress.
- The class CHandshakes listens on a socket, and doesn't process handshake headers at all.
Figuring out hub and leaf needs, roles and connections
On the Gnutella network, a program can be acting in one of two roles: ultrapeer or leaf. Gnutella 2 has a similar set of network roles, called hub and leaf. A computer can be a hub or a leaf, or not know yet. It can be a hub to some remote computers and a leaf to others. It can tell a remote computer it is a hub, isn't yet a hub but could become one, or isn't and can't. It can advertise that it needs more hub connections, or more leaf connections. Peer-to-peer programs devote a lot of code to figuring out hubs and leaves.
- CNeighboursWithConnect adds member variables like Neighbours.m_bG1Ultrapeer that is true if we are acting as a Gnutella ultrapeer to at least one connected computer.
- CShakeNeighbour has member variables and code for the X-Ultrapeer and X-Ultrapeer-Needed headers.
- CNeighboursWithConnect adds methods that tell if we are or could become an ultrapeer to the CNeighbours object.
Pushing open a new connection and dealing with push packets
If we're behind a firewall, a remote computer won't be able to contact our listening socket to open a new TCP connection with us. But, we're all on the Gnutella network, and might be able to exchange short packet messages through a third computer. The remote computer sends us a push request with its IP address, and we connect to it.
Routing packets and picturing the shape of the network from here
There is no central server that organises the shape of a peer-to-peer network. It's each computer's job to look at their own connections, and change things to make the network more efficient. A peer-to-peer program receives packets from one computer, and sends them to others. It must decide how to relay each packet.