where: -d run as a daemon with no interactive keyboard interface -v print version info and exit w/o starting the server -fcfgfile means to use "cfgfile" as the server runtime configuration file instead of the default.
ISIS provides runtime logging capability for all data-taking system traffic including precision time tagging. The ISIS runtime communications log provides a single point of logging for an instrument system, greatly facilitating troubleshooting by preserving the full interprocess communication history between different data-taking system elements.
Messages passed by ISIS follow the ICIMACS Messaging Protocol Version 2.5 (IMPv2.5) used by all OSU-built instruments. The details of this protocol are described in the IMPv2.5 Specification (300k PDF).
ISIS is a replacement for the older ariel/WC system we used in the past. ISIS assumes all of the basic functions of the ariel daemon and most of the functions of the old WC ("Workstation Computer") MS-DOS PC system. In 2002 we retired the last WC-based MS-DOS system and all OSU instruments since have used ISIS.
Executive Commands (keyboard-only):
QUIT Terminate the server session and exit
HOSTS Print a table of all currently known client hosts on the screen
INFO Display detailed server information on the screen
HELP List of server commands
VERBOSE Echo all server communications to the screen
CONCISE Suppress echoing of communications (opposite of VERBOSE)
HISTORY List recently typed commands (like Unix history)
Communications Control:
PING Communications initialization request, responds with a PONG
PONG Communications initialization acknowledge, no response required
RESTART Warm restart the server, clear runtime tables, PING fixed ports
PORTS lists the active tty ports
FLUSH n Flush tty port n of junk
REMOVE xx Remove host xx from the client host table
UDPPING ip port Ping the named UDP socket port
Utilities
VERSION Return program version info
HOST xx Return info on a client host xx (or xx=all)
STATUS Return a server status message
CONFIG Displays current configuration with instrument info
TIME Report the UTC time and date as FITS-like keywords
-LOG Disable the server's runtime log temporarily
+LOG (Re)Enable the server's runtime log after -LOG
Note: while the command names are given in all caps to distinguish them, all ISIS commands are case-insensitive):
# # ISIS Server Runtime Initialization File # # MODS1 LBT Observatory Left Direct Gregorian Configuration # # R. Pogge, OSU Astronomy Dept. # pogge@astronomy.ohio-state.edu # 2010 June 21 # ################################################################ # ISIS Server Info ServerID IS ServerPort 6600 ServerLog /lhome/Logs/ISIS/isis LogDate UTC # List all serial ports we might use here, max 8 # Comment out any unused ports to avoid startup errors TTYPort /dev/ttyD2 TTYPort /dev/ttyD3 # Define any preset UDP ports we wish to ping on startup or restart, max 8 # MODS1 LBT Config: # M1.IE on mods1 (192.168.139.130) port 10700 # Caliban Agents: M1.CB and M1.CR on mods1data (192.168.139.131) # ports 10601 and 10602, respectively # MODSENV Agent: on mods1data (.131) port 10901 # MODS1 Dashboard on mods1 192.168.139.130 port 20801 # LBTTCS Agent: TC on mods1, port 10801 UDPPort 192.168.139.130 10700 UDPPort 192.168.139.131 10601 UDPPort 192.168.139.131 10602 UDPPort 192.168.139.131 10901 UDPPort 192.168.139.130 10801 UDPPort 192.168.139.130 20801 # Runtime Flags #Verbose # Instrument ID (optional) Instrument MODS1
The # character denotes comments, and appears in the first character of the line. Inline comments are not supported by this simple parser. Blank lines are ignored by the parser, and may be included in any number desired to improve the human readability of a config file.
Runtime parameters are designated by keyword/value pairs, for example:
ServerID IS
If an unknown keyword is given in a config file, a warning message is printed but the rest of the config file continues to be read and processed. Unknown keywords are ignored.
In operational settings, a default runtime config file is provided, defined at compile time by the ISIS_CONFIG parameter in the isisserver.h header file. A user can override this default by giving the name of the desired config file on the command line.
Many runtime parameters can be changed during a session with interactive commands or via remote command interfaces like isisCmd. However, any changes made to these parameters will not be preserved for future sessions. This provides a way to safeguard a public server configuration against changes by careless users (or forgetful support staff who ignore the protocol that after tweaking a server during troubleshooting, they should stop and restart ISIS to ensure that the default startup configuration is recovered).
ISIS uses select() for I/O multiplexing. We have found that even in fairly busy instrument systems with a lot of traffic, the actual data rates for the message is small enough that on modern computers a single-threaded ISIS can keep up, even with incoming messages spaced by as little as 10us apart. Thus ISIS is kept simple and does not require multithreading.
UDP sockets were adopted because we noted that ISIS is just for message passing, and the messages in our system never exceed a few hundred bytes in length (the maximum limit is 4096 bytes including the ASCII 13 terminator character). This is well below the maximum number of bytes per packet, and so we would never be subject to problem of UDP not guaranteeing the order of packet arrival in a multi-packet datagram.
Similarly, none of the communications traffic in an ICIMACS data-taking system requires use of streams or persistent connections. In many enviroments, both lab and field deployments, a connection-less socket is preferred. The ISIS server can be made very lightweight, without the difficult parts of a multi-connection TCP server to guard against file descriptor accumulation, dangling sockets, hung connections, and so forth. Because an ICIMACS message is a datagram, using UDP sockets was the right tool for the job.
Note that individual data-taking system programs, as needed, will include TCP socket clients, for example to communicate with some telescope control systems (e.g., the BAIT protocol system based on TCP sockets at the MDM 1.3m telscope), or to interface with various internet appliances that use TCP (e.g., Comtrol DeviceMaster network serial port servers). What the different programs do not implement are TCP server functions, keeping them simple and lightweight.
The ISIS messaging system has proven fast, flexible, and very robust with tens of thousands of operational hours logged at many observatories with a variety of instruments from simple imaging cameras to a complex, multi-mechanism spectrograph like MODS.
ISIS uses the GNU readline and history utilties for the CLI when enabled.
Starting with the MODS1 testing at LBT in 2010, we rarely if ever run ISIS in interactive command mode, but instead run it as a background task via the -d runtime option.
2003 Jan 4 - initial testbed version [rwp/osu]
2003 Jan 15 - first production version, deployed at CTIO [rwp/osu]
2003 Feb 15 - post-run updates from CTIO field testing [rwp/osu]
2003 Sept 14 - Modified extensively to generalize code and
introduce better timing practices [rwp/osu]
2004 May 11 - overhauled package organization, now compiles under g++
(not pretty at first), also introduced Doxygen markup
for all comment blocks to bring up to our current
documentation standard [rwp/osu]
2009 Mar 18 - modifications for version 2.x, including daemon mode
and cleanup of old junk we never use anymore [rwp/osu]
2010 Apr 14 - further modifications for operation as a background
pseudo-daemon, introducing the -d option [rwp/osu]
1.3.9.1