]> April 10, 1999 Jochen Friedrich

jochen@scram.de

Gregory McLean

gregm@comstar.net

John Schulien

jms@uic.edu

Craig Small

csmall@eye-net.com.au

This documentation is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA For more details see the file COPYING in the source distribution of GXSNMP. GXSNMP is a network management application that is intended to grow in the future to provide all of the features one would expect to find in the commerical offerings. FIXME! &widgets; FIXME! SNMPv3 is currently defined in the RFCs 2271 - 2275. RFC2271 gives an overview about SNMPv3 and defines separate modules for the standard implementation. This document explains how these modules are implemented in this library. Additionally, draft-ietf-snmpv2-coex-??.txt is of interest on how to combine SNMPv3 and older versions together in one application. This section will deal with the actual implementation of SNMPv3 in the snmp library. We also will give reference to the relevant Request For Comments (RFC). RFC 2271 defines the following modules dispatcher (RFC2272) message processing subsystem (RFC2272) security subsystem (RFC2274) access control subsystem (RFC2275) application (RFC2273) The dispatcher is special in that only one instance of dispatcher can exist in a given SNMP entity. Even an application may register different modules with the SNM engine for different functionality (e.g. a combined SNMP agent with proxy). The dispatcher is implemented in C using a set of functions, while all other modules must provide their interface as struct of functions to the dispatcher in init time (poor mans objects :-) ). Additionally, the dispatcher must take care of the configuration file and provide an API for the SNMP modules to read and write their variables. These are the primitives of the RFC2271 properly sorted by module: application processPdu processResponsePdu dispatcher sendPdu returnResponsePdu registerContextEngineID unregisterContextEngineID message processing subsystem prepareOutgoingMessage prepareResponseMessage prepareDataElements releaseState access control subsystem isAccessAllowed security subsystem generateRequestMsg processIncomingMsg generateResponseMsg Additionally, an initialization function must be provided by each module and a point of registration by the dispatcher for the different types of modules. Order of Initialization dispatcher is initialized Each message processing subsystem is initialized. It will resgister with the dispatcher by model number and provides a struct of the primitives. Each security subsystem registers. Each access subsystem resisters. Now the application can start registering their services using the public function registerContextID. &turtletalk;