Implementing protocol routing

As described in chapter 3, message routing is specified to a high detail in Gnutella. The GnutellaMonitor is responsible for creating jobs that handle incoming messages. Given a ByteBuffer that, according to the GnutellaReader class, should contain a complete message and the corresponding SocketChannel a job is created to handle the message. This makes it suitable to create small job classes for each message type, which gives us five job classes for messages:

GnutellaPingJob

ThreadJob
Handles incoming or outgoing Ping messages. If it is an incoming message a Pong is sent as a response.

GnutellaPongJob

ThreadJob
Determines if a Pong message is destined for us. If it is not, it is forwarded to the appropriate host.

GnutellaQueryJob

ThreadJob
Handles incoming or outgoing Query message. If it is an incoming message a lookup in the repository could result in the transmission of QueryHit messages. The query is forwarded to other neighbouring nodes.

GnutellaQueryHitJob

ThreadJob
Determines if a QueryHit message is destined for us. If it is not, it is forwarded to the appropriate host.

GnutellaPushJob

ThreadJob
Determines if a Push message is destined for us. If it is not, it is forwarded to the appropriate host.

Since each job is based on a single message type it is possible to take two approaches. First, we could implement small classes that encapsulate the contents in a message. This involves creating an abstract base class GnutellaMessage and then implementing subclasses such as GnutellaPing and GnutellaQueryHit. The GnutellaMonitor instantiates the appropriate class depending on the contents of the header, the message class parses the payload if necessary and the message object is passed to the constructor of the job. This approach causes the work performed by each job to be reduced, but it increases the amount of work performed in the GnutellaMonitor.

The second approach is the opposite of the first one. Instead of having the GnutellaMonitor create message objects that parse the contents of a ByteBuffer, the ByteBuffer could be passed directly to the job. The job is then responsible for parsing the message and it could eliminate the need for message classes entirely. The problem with this approach is that erroneous messages could cause the PeerBackEnd to dispatch events. An adjustment to the PeerBackEnd that checks if the job completed successfully would remove this problem. This also requires a minor adjustment to the ThreadJob class.