6.1.2 Der SNMP-TrapController  

Die Aufgabe des TrapController läßt sich in zwei Kategorien einteilen (siehe 5.2.4):

1.

Das Empfangen einer SNMP-Trap-PDU am Port 162.

2.

Die Abbildung des empfangenen Traps auf eine OSI-Notifikation und deren Zuordnung zu einer OSI-Instanz.

Der TrapController besteht aus einer Instanz der C++-Klasse SNMPTrap und ist abgeleitet von der C++-Klasse ResourceAccess. Die letztere stellt eine Implementierung der in 3.2.1 vorgestellten Resource Access-Komponente dar und wird vom Managed Object/Agent Composer bereitgestellt. Damit steht nach dem TMN-Referenzmodell ein m-Interface zur Verfügung, also die Möglichkeit, SNMP-Traps zu empfangen und zu bearbeiten (siehe 5.2.4). Dieses m-Interface wird folgendermaßen realisiert:
Im Agent-Prozeß des Gateways, genauer in der CoreAgent-Komponente, wird eine zentrale Endlosschleife (Ereignisauswahlschleife) implementiert. Alle Requests des Infratops werden dort an speziellen Sockets empfangen und deren Bearbeitung ausgelöst. Die CoreAgent-Komponente ermöglicht es einem Entwickler, einen eigenen Socket mit einer Instanz einer von ResourceAccess abgeleiteten C++-Klasse in dieser Ereignisauswahlschleife einzubinden. Sobald eine Nachricht an diesem Socket anliegt, wird eine spezielle Methode (doRead) der ResourceAccess-Klasse aufgerufen. Diese Methode ist als rein virtuell

virtual doRead(...)=0;

definiert, das heißt, sie muß von einer abgeleiteten Klasse explizit neu realisiert werden. Die Aufgabe der C++-Klasse SNMPTrap ist es nun, einen UDP-Socket an den Port 162 zu binden. Anschließend wird dieser Socket und eine Instanz dieser Klasse selbst an der zentralen Ereignisauswahlschleife angemeldet. Es wird weiterhin in dieser Klasse die als virtuell definierte, geerbte Methode doRead implementiert. Diese wird von der zentralen Ereignisauswahlschleife aufgerufen, sobald ein Trap am Port 162 angekommen ist. In dieser Methode erfolgt die Abbildung des empfangenen Traps auf die OSI-Notifikation ,,internetAlarm`` aus [IIMCIMIBTR] nach den Regeln aus [IIMCPROXY]. Zuletzt muß diese Notifikation noch einer OSI-Instanz zugeordnet werden. Dies erfolgt nach folgendem Algorithmus:

1.

Falls nicht festgestellt werden kann, von welchem SNMP-Agenten der Trap stammt, bzw. dieser Agent nicht vom Gateway überwacht wird, soll die Notifikation von der Instanz der Klasse ,,cmipsnmpProxy``weitergeleitet werden.

2.

Falls der SNMP-Agent vom Gateway überwacht wird, dieser die MIB-2 aber nicht unterstützt, soll die Instanz der Klasse ,,cmipsnmpProxyAgent``, die diesen Agent repräsentiert, die Bearbeitung der Notifikation auslösen.

3.

Im letzten Fall (das heißt, falls der SNMP-Agent vom Gateway überwacht wird und die MIB-2 unterstützt), soll die Instanz der Klasse ,, internetSystem``, die die MIB-2-Gruppe ,,system`` dieses SNMP-Agenten repräsentiert, die Weiterleitung der Notifikation übernehmen.

Die Weiterleitung der Notifikation zum Event Handler und damit zu den EFDs erfolgt mit Hilfe einer Methode, die standardmäßig vom Managed Object/Agent Composer in jede Instanz integriert ist.