The C++ Chain of Responsibility Pattern and Network Events

More Details of the EventHandler Class

The member function HasEventSupport() in Listing 1 indicates if a given object of this class provides event support. As mentioned above, the chain of responsibility pattern allows objects to either provide support or to pass the event along via the _successor pointer. If the object of this class wants to provide a specific event handler it calls SetHandler(EventHandler*, Event). The last member function HandleEvent() is used to implement the event handler itself.

Two member properties are provided in the EventHandler base class: _successor and _event. As mentioned earlier, the _successor is a pointer to the next handler in the chain or responsibility, i.e., if I don't handle the event then I pass it on to the _successor. The event in question is stored in the _event variable.

Let's now finally see how this base class is used to provide the chain of responsibility.

A Connection Subclass Of EventHandler

Given that we're using a devolved model for event management, we can now define a Connection class in Listing 2. Remember that LSP (LSP123 and its backup) in Figure 1? Well, this is an EventHandler subclass to represent such logical connections. As you can see in Listing 2, the Connection class is derived from EventHandler in with the devolved model we're using.

class Connection : public EventHandler {
public:
  Connection(Event t) : EventHandler(0, t) { }

  virtual void HandleEvent(); };

void Connection ::HandleEvent() { }

class Path : public Connection {
public:
  Path::Path(Connection* w, Event t) : Connection(0) {
    cout << "Now in the Path constructor\n";
    SetHandler(w, t);   }

So, Connection is a generic subclass of EventHandler. I say generic because Connection can be used (via inheritance) to model other types of logical network connections (e.g., IP tunnels) depending on the deployed network technology. We can think of Connection as a placeholder for more specialized subclasses in the same way as "Human" is a generic placeholder type for "Male" and "Female".

Listing 2 also defines another class called Path derived from Connection. Path is a means of storing a route for an LSP (such as LSP123, which follows the path R2-R3-R4-R5 in Figure 1). Listing 3 illustrates the last class of interest to us: the Lsp class also derived from Connection.

class Lsp : public Connection {
public:
  Lsp::Lsp(char* lspID, Connection* w, Event t) : Connection(0) {
    lspName = lspID;
    SetHandler(w, t);   }

  void HandleEvent() {
    if (HasEventSupport()) {
      cout << "\nAt last, here's some LSP Event support:\n";
      cout << "Lost the path for LSP: " << lspName << "\n\n";
      cout << "Rerouting to backup LSP R2R7R6R5"\n\n";
      cout << "We need more bandwidth on backup LSP" << "\n\n";
    }
    else
      EventHandler::HandleEvent();  }
private:
  char* lspName; };

The Lsp class acquires (via inheritance) all the capabilities of EventHandler as well as adding a few wrinkles of its own. As you can see, Lsp implements the HandleEvent() member function. This member function is defined as virtual in the EventHandler base class, so subclasses are free to redefine it as required. In the case of the Lsp class, the event support provided is to print out an informative message.

Now, let's put it all together and build the chain of responsibility, as illustrated in Listing 4.

  Connection* connection = new Connection(No_Event_Support);
  Lsp* lsp = new Lsp("LSP123", connection, LINK_1_BROKEN);
  Path* path = new Path(lsp, No_Event_Support);
  path->HandleEvent();

At the top of the chain is a Connection* object. The next level in the chain is an Lsp* object. Finally, at the bottom of the chain is a Path* object. As you can see from Listing 4, to start the event processing, we simply call path->HandleEvent(). This simulates the link failure from Figure 1. Listing 5 illustrates part of the program output (excluding initialization in the constructors).

No support from Path - Sorry!
Calling the base class event handler
HandleEvent () calling into successor

At last, here's some LSP Event support:
Lost the path for LSP: LSP123
Rerouting to backup LSP R2R7R6R5
We need more bandwidth on backup LSP

The first line of Listing 5 shows us that the path object can't offer any help. This is because the Path class implements a very thin HandleEvent() method. Because the path object can't process the event, it calls the base class HandleEvent() method. This then results in a call to the Lsp HandleEvent() method. As the second last line in Listing 5 illustrates, we finally get some help from this object in the form of a message indicating that the LSP is rerouted to a new path. Note that the event handler also gives us a hint that the backup LSP may have inadequate bandwidth. The latter could then initiate a call to a network modeling application to try to find an optimal path.

So, that's it! That's our chain of responsibility passing the event around like a hot potato until an appropriate handler is found.