NAME

snmpMonitorSpawn( ) - spawn tMonQue to run snmpQueMonitor( )

SYNOPSIS

void snmpMonitorSpawn (void)

DESCRIPTION

This function spawns the tMonQue task to run snmpQueMonitor( ) a function that waits on the message queue that subagents use to leave messages for the master agent. The snmpQueMonitor( ) waits forever on the master agent's message queue. When message comes in, it is interpreted using an SA_MESSAGE_T structure, which is defined in ipcLib.h as:

typedef struct SA_MESSAGE_S 
   { 
   int            msgType; 
   MSG_Q_ID       saId; 
   EBUFFER_T      mesg; 
   } SA_MESSAGE_T;

A switch internal to snmpQueMonitor( ) handles the message according to the value of the msgType member.

If the message type is CALL_QUERY_HANDLER, the message is a response to a query from the master agent. The buffer referenced in the mesg is then transferred to the local message queue monitored by tSnmpd, where a masterIpcRcv( ) routine is waiting for a query response from a subagent.

If the message type is CALL_REG_HANDLER, the message is a control message such as a registration request, a deregistration request, or a trap. To respond to such requests, snmpQueMonitor( ) passes the buffer in mesg on to snmpMasterHandlerWR( ).

If the message in the buffer passed to snmpMasterHandlerWR( ) is not correctly formed, the returned function value indicates failure and snmpQueMonitor( ) drops the packet.

If the buffer passed to snmpMasterHandlerWR( ) is a correctly formed registration request, snmpMasterHandlerWR( ) adds the specified objects to the master agent's MIB tree. If the buffer contains a correctly formed deregistration request, snmpMasterHandlerWR( ) removes the specified objects from the master agent's MIB tree. In both cases the returned value of snmpMasterHandlerWR( ) indicates success and its pBuf parameter contains a message that snmpQueMonitor( ) forwards to the subagent that sent the message.

In the case of a successful registration request, the message sent to the subagent contains a group ID for the objects just added to the master agent's MIB tree. When the subagent deregisters itself, it includes this ID in its deregistration message to the master agent. It also uses this group ID when it must register instances of the object just registered.

If the buffer passed to snmpMasterHandlerWR( ) contains a trap, the returned function value is SA_TRAP_REQUEST, the value extracted from the opcode2 member of the header associated with the message. The message itself (minus the header) is a varbind list. It is returned using the pVblist parameter. The current implementation of snmpQueMonitor( ) just drops this message. However, you can rewrite snmpQueMonitor( ) to make a snmpIoTrapSend( ) that forwards the varbind list to the SNMP manager. Likewise, you can implement appropriate responses to other opcode2 values. Currently, subagent.h defines symbolic constants for opcodes 1 through 12 (with opcode 11, SA_TRAP_REQUEST, reserved for trap requests). If necessary you are free to use the remaining opcodes for message types specific to your implementation.

If your transport needs require that you rewrite masterIoLib to use an IPC other than message queues, you might need to modify this function, which is called from snmpIoMain( ) just before a call to snmpIoBody( ). For example, if you use sockets as your IPC between the SNMP master agent and its subagents, tSnmpd could monitor the socket connection with the SNMP manager as well as the socket connections with the SNMP subagents.

ASYNCHRONOUS COMMUNICATION

The shipped version of snmpQueMonitor( ) uses snmpMasterHandlerWR( ) and thus processes messages asynchronously. However, if necessary, you can rewrite snmpQueMonitor( ) to call snmpMasterHandlerAsync( ) instead. For more information on snmpMasterHandlerAsync( ), see its reference entry.

RETURNS

N/A

SEE ALSO

masterIoLib