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 |
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.
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
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,
accepts the connection request and creates a client (see
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,
reads the message from the connection and calls
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
read the SNMP message and to extract the MEDS message embedded in the SNMP
agentRead() examines the type of the MEDS message
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.
The embedding of a MEDS message in an SNMP message takes place in
agentWrite() outputs the MEDS message as is.
The extraction of a MEDS message from an SNMP message takes place in
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:
The routing of different types of MEDS messages to the appropriate TPCE
client connection takes place in
% tsi [-debug] [-vperror] [-commands port] [-events port] [-status port] agent[@host]
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.