NARA 5SDH-2
NARA 5SDH-2
It’s purpose is to provide a way of obtaining parameter values from the AccelNET control system for use by other types of programs, perhaps running on other computers using other operating systems without having to compile special bits of code for those systems.
inet_reqpar reads stdin for a Label-RefName pair. When a Label-RefName pair is received a request is formatted and sent to dbman to obtain the value of the parameter.
When the answer is obtained from dbman a string containing four fields is written to stdout. The fields are: Label, RefName, Value, and Status. The fields are separated by a "|" and the string is terminated by a line feed.
It is expected that the user will write a program to utilize the services provided by this program. Since all information is exchanged in ascii writing programs in various languages on various types of systems shouldn’t be difficult as long as the language of choice can establish network connections and process strings.
After this program is properly installed it may be tested by using telnet. See the "testing the connection" section below for an example of this.
See the "inetd and xinetd overview" section below for more information about inetd and xinetd and programs like this one.
See the appropriate configuration section below for information about configuring inetd and xinetd for use with this program.
A "|" is used to separate fields within the the command.
A line feed, a carriage return, or a line feed carriage return combination may be used to terminate a command. All commands must be terminated.
Parameter tagnames are given as two fields, "label" and "refname". For example "SETUP|TotPartE<lf>".
It is used to flush a qued up list of parameter value requests to dbman(8) .
See the "testing the connection" section below for an example using this command.
The client closing the connection will also cause inet_reqpar to exit.
"depth<lf>" queries for the current depth setting.
See the "testing the connection" section below for an example using this command.
For example, "terminator|cr<lf>" sets the response terminator to a CR.
"terminator<lf>" queries for the current terminator setting.
A program using them only has to perform I/O using the stdin and stdout. When a new connection to the "super server" is made the server launches the service provider program and plugs the network connections into it.
Each service uses a separate port number. Two common examples of services "front ended" by inetd are ftp, and telnet,
Each time a client application connects to a service provided by inetd a child program is spawned and stdin, stdout, and stderr are plugged into the socket connections created by inetd.
This relieves an individual program from having to be written with network code to create and service sockets. The program is simply written to accept commands from stdin and to write responses to stdout.
Both "super server" programs do the approximently the same thing,
inetd uses a configuration file to set up a series of listener sockets to provide services using tcp/ip.
xinetd is the newer program. xinetd uses a subdirectory containing a configuration file for each provided service.
Generally this documentation refers to both as inetd where reasonable.
First you must add an entry to /etc/services. This is used to associated a port number with a name so that the port number can be used elsewhere without having to remember the numeric value.
In testing at NEC we used "reqpar" as the name and 6180 as the port number. The port number (and name) may be changed to fit the needs of the target system.
The services entry should look like this:
reqpar 6180/tcp
Next change directories to /etc/xinetd.d and create a file called "reqpar".
The file should have the following contents at a minimum:
service reqpar
{
socket_type = stream
wait = no
user = csadmin
log_on_success += USERID
log_on_failure += USERID
server = /AccelNET/ubin/inet_reqpar
server_args = localhost
only_from = localhost
disable = no
}
The only_from directive limits access to connections originating from the local computer. If you wish to use this service from another box you should change this directive appropriately. See the xinetd(8) manual pages for more information.
Next restart xinetd by typing:
/etc/rc.d/init.d/xinetd restart.
Test the reqpar service using the instructions given below in the section "testing the connection".
inetd requires entries be added to /etc/services.
Follow the instructions given in "xinetd setup" for adding the required entries to /etc/services.
Next you need to add a line to /etc/inetd.conf. The line should look like this:
reqpar stream tcp nowait csadmin /AccelNET/ubin/inet_reqpar inet_reqpar localhost
Note that the line may be wrapped in the manual page due to it’s length.
Next you must restart inetd for the changes to take effect.
Type: /etc/rc.d/init.d/inet restart
If you type "netstat -ta" you should see an entry similiar to "*.reqpar" in the "Local Address" column. This shows the listener connection has been established.
Test the reqpar service using the instructions given below in the section "testing the connection".
However, before that job may begin the service may need to be tested to ensure that it is working properly and to demonstrate it’s capabilities. Telnet may be used for this purpose.
This section demonstrates setting up a connection with telnet and performing the various commands.
We will use the "SETUP TotPartE" parameter and similiar parameters for this demonstration because they are generally available on all AccelNET systems.
Connect to the service by typing: "telnet localhost reqpar". If connecting remotely replace "localhost" with the hostname of the target machine.
The third argument "reqpar" is the port number and is looked for in the /etc/services file to determine the integer port number.
If you are running remotely you may need to replace this parameter with the integer value (i.e. "telnet some_host 6180") if the copy of the /etc/services file on the remote machine has not been editted to add the information.
After connecting you can retrieve the "SETUP TotPartE" parameter value by typing:
SETUP|TotPartE<lf>
inetd_reqpar will reply with:
SETUP|TotPartE|0.00000e00|ERRok<lf>
The "0.0000e00" value will be replaced with whatever the current value of the parameter is.
ERRok is the status of the parameter. In this case all is ok, see the errcodes(7) manual page for more information.
Parameters may be retrieved in "batches" by using the depth command to set the maximum batch size and using the flush command to execute the batch.
It’s done like this:
Set the batch length.
type: "depth|10"
Que up parameters:
type: "SETUP|TotPartE"
type: "SETUP|TotMachE"
type: "SETUP|TotInjE"
Now there are three parameters qued up. Obtain the values by typing "flush".
inet_reqpar will reply with:
SETUP|TotPartE|0.00000e00|ERRok<lf>
SETUP|TotMachE|0.00000e00|ERRok<lf>
SETUP|TotInjE |0.00000e00|ERRok<lf>
The program may be exited by typing "quit<lf>".
If the que depth is set to a number less than the number of parameters being qued a flush will occur automatically when the number of parameters qued equals the depth setting.
The whole que depth thing is dubious.
