↑ On-the-Shelf Software ↑

GEONius.com
23-Dec-2015
 E-mail 

tsi - TPCE SNMP Interface

NOTE: Back around 1995, another team on our project was considering implementing an SNMP interface between our VxWorks-based, real-time boards and the Unix-based TPCE client GUI. I whipped the team up a skeleton program that would sit between the GUI and the front-end, real-time sytem, responding to TCP/IP communications from the GUI and UDP packets from the front-end. My program did not implement the actual SNMP communications and processing. We had been looking at the then-current Unix SNMP library that had been ported to VxWorks. This SNMP interface was never implemented and this program was never developed further. At the time, the other team did appreciate me writing this for them!

Program tsi provides TPCE with an SNMP link to the front-end controller. MEDS commands issued by TPCE to the Master Controller are embedded in SNMP commands and forwarded to the SNMP agent running on the Master Controller. MEDS response, event, and status block messages received from the front-end agent are extracted from the SNMP messages and returned to TPCE:

                                      Host | Front-end
                                           |
                 TPCE  <----->  tsi  <-----|----->  Agent
                                           |

Sample Invocation

If the Master Controller is running on front-end "vxlzp1", then tsi might be run as follows on the TPCE host:

    % tsi -commands 3000 -status 3100 -events 3200 161@vxlzp1

3000, 3100, and 3200 are the network ports at which tsi will listen for command, status block, and event connection requests, respectively, from TPCE. "161@vxlzp1" specifies the UDP port and host name of the SNMP agent on the front-end. tsi can be run on a workstation separate from TPCE as long as TPCE is configured to connect to tsi's host.

Implementation Overview

tsi is an I/O event-driven process. During initialization, tsi creates listening ports (see port_util.c) for each type of TCP/IP connection it accepts from TPCE: a bidirectional command/response connection, a write-only (from tsi's viewpoint) events connection, and/or a write-only status block connection. tsi also creates an agent (see agent_util.c) through which it will send messages to and receive messages from the SNMP agent on the front end.

The listening ports and the agent are registered as input sources with the NIX I/O event dispatcher. tsi then relinquishes control to the NIX dispatcher.

For the purpose of illustration, assume that tsi is listening for command connection requests on port 3000 (the standard MEDS command port) and that TPCE requests such a connection. When the NIX dispatcher detects the connection request on port 3000, it invokes the callback registered for listening port 3000. The callback function, portAnswer(), accepts the connection request and creates a client (see client_util.c) for the new TPCE connection. This connection is registered as an input source with the NIX dispatcher.

When TPCE sends a MEDS command to tsi, the NIX dispatcher will detect the pending input on the client connection and invoke the callback registered for the connection. The callback function, clientReadInput(), reads the message from the connection and calls agentWrite() to forward the MEDS message, embedded in an SNMP message, to the SNMP agent on the front end.

After receiving and processing the command, the Master Controller returns a response message via the front-end SNMP agent. When the NIX dispatcher detects input from the agent, it invokes the callback registered for tsi's side of the UDP "connection" with the agent. The callback function, agentReadInput(), calls agentRead() to read the SNMP message and to extract the MEDS message embedded in the SNMP message. agentRead() examines the type of the MEDS message before calling clientWrite() to relay the MEDS message to the appropriate TPCE client: response messages are written to the command connection, event messages are written to the events connection, and so on.

If a client connection breaks (e.g., if TPCE core dumps), the connection's registration with the NIX dispatcher is removed. When the associated listening port receives a new connection request, a new client connection will be created as described above.

Embedding MEDS Messages in SNMP Messages

The embedding of a MEDS message in an SNMP message takes place in agentWrite() (see agent_util.c); currently, agentWrite() outputs the MEDS message as is.

The extraction of a MEDS message from an SNMP message takes place in agentRead(); currently, agentRead() simply reads the MEDS message as is off the network.

Long MEDS messages may need to span multiple SNMP messages. The scheme chosen for embedding MEDS messages in SNMP messages should take this into account. The details of the scheme will, I expect, be confined to the following tsi functions: agentIsReadable(), agentRead(), and agentWrite().

The routing of different types of MEDS messages to the appropriate TPCE client connection takes place in agentReadInput().

Some Issues

  1. tsi assumes, but does not enforce, a single TPCE connection per connection type. For example, if a client connection exists for events and a new events connection is requested, the new connection will replace the existing connection as the destination for event messages received from the SNMP agent. The existing connection continues to exist, albeit as an "orphan", until the connection is finally broken.

  2. SNMP object names for MEDS communications need to be defined.

  3. Event and status block messages, being asynchronously generated by the Master Controller, should probably be sent to tsi as SNMP, enterprise-specific, asynchronous traps (ASTs). This approach would require establishing tsi as the destination for the front-end agent's ASTs. The mechanics of doing so and the disposition of "non-MEDS" ASTs are TBD.

Invocation:

    % tsi [-debug] [-vperror]
          [-commands port] [-events port] [-status port]
          agent[@host]

where

-debug
enables debug output (written to stdout).
-vperror
turns vperror() message output on. vperror() messages are low-level error messages generated by libgpl functions; normally, they are disabled. If enabled, the messages are output to stderr.
-commands port
-events port
-status port
specify the network server ports (i.e., service name or port number) at which tsi will listen for connection requests from TPCE. If a particular type of port is not specified, then it will not be monitored; e.g., tsi may only be acting as a source (with respect to TPCE) of event messages.
agent[@host]
specifies the service name and host of the SNMP agent to which tsi sends command messages and from which it will receive response, event, or status messages. The host name defaults to the local host if not explicitly specified.

Alex Measday  /  E-mail