How an Agent Functions

Agents are the servers in the client and server relationship. Agents listen on well-known port 161 for request packets from managers. In addition to the protocol and application layers, agents must also communicate with the operating system kernel.

Most of the information in the Internet-standard MIB is maintained by kernel processes. The actions associated with a set request are often implemented as ioctl commands. In addition, the kernel may generate asynchronous notifications called traps. Some MIB information may be managed by another application, such as the gated daemon. The Agent Function figure (Figure 1) outlines the function of an agent.

Figure 1. Agent Function
This diagram shows that the kernel within the agent additionally gets and saves values, and performs set actions. The agent's application processes requests, creates replies, and sends trap packets. Two of the protocol layer tasks are decoding requests and encoding replies. There is communication between the agent and the network and also the gated Daemon that contains community names.

One of the tasks of the protocol layer is to authenticate requests. This is optional and not all agents implement this task. If the protocol layer authenticates requests, the community name included in every request packet is used to determine what access privileges the sender has. The community name might be used to reject all requests (if it is an unknown name), restrict the sender's view of the database, or reject set requests from some senders. A manager might belong to many different communities, each of which may have a different set of access privileges granted by the agents. A manager might generate or forward requests for other processes, using different community names for each.