Developers.Refactor.Connection

From Shareaza Wiki
Revision as of 20:09, 20 June 2009 by Kevogod (talk | contribs) (1 revision)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

How the Connection Code of Shareaza is Designed

From looking at CConnection and CNeighbour, here are some notes about how this part of the source code appears to be designed.

All the classes in this part of the code fit into a very long inheritance tree. CConnection is the root. CNeighbour inherits from CConnection. More classes inherit from Neighbour, and even more from them.

CConnection wraps a socket and has methods that read and write data. It does everything that is in common with all the classes that inherit from it. If a job is specific to one of these classes and not another, then that job has to be taken care of further along the chain.

This is the rule that governs where a method goes. It keeps code duplication to a near-zero level. But, it also spreads jobs over many different classes. For instance, CConnection reads some headers. These headers are common to all the networks Shareaza browses, so the task of reading them made it all the way to the root object in the inheritance tree.

The long inheritance tree also creates a lot of member variables. CConnection has a few, and then CNeighbour takes all of them and adds even more. Beyond Neighbour, someone reading the code has to figure out if a member variable is from Neighbour, or all the way back to Connection. This can get confusing.

Connection Design Ideas

Instead of having classes like CConnection and CNeighbour, I would make one called CSocket. Connection and Neighbour are two classes instead of one, and one inherits from the other. This is needlessly complex. Connection correctly wraps a socket, but also starts to do some higher-level peer-to-peer protocol work. This isn't encapsulated the right way. CSocket would:

Wrap a socket:

  1. Specify the options that Shareaza wants
  2. Contain the messy Win32 calls
  3. Provide a simple interface for opening, closing, reading and writing
  4. Be able to listen and accept incoming connections

Provide additional features:

  1. Meter and throttle bandwidth
  2. Turn on Zlib compression like a switch
  3. Avoid connecting to computers on the security watch list

It would not do anything related to a peer-to-peer network. It wouldn't touch handshake headers, for instance.

Imagine if the platform offered the perfect implementation of a socket for Shareaza to use. Since it doesn't, we can just write it ourselves. This is what CSocket would be designed to be.