Xic has the capability of operating as a daemon process, servicing requests for processing of design data. This allows Xic to be used as a back-end for automation systems designed by the user or third parties.
To start Xic in server mode, the -S option is used, as
xic -S[port]
This causes Xic to start without graphics, go to the background, and listen to a system port for requests. The port number used can be provided on the command line immediately following the ``-S''. If not given on the command line, the ``xic/tcp'' service is queried from the local host. This will come up empty unless the ``xic/tcp'' service has been added to the host database, usually by adding a line like the following to the /etc/services file:
xic 3002/tcp #Whiteley Research Inc.where the port number 3002 is replaced by the desired port number. If there is no port assigned for ``xic/tcp'', port 3002 is used.
If the environment variable XTNETDEBUG is defined, Xic will not go into the background, but will service requests while printing status messages to the standard output. This may be useful for debugging.
The user's application should open a socket to this port for communications. Only one process can access the port at a given time. For testing and experimental purposes, the telnet program can be used to connect to the Xic daemon. After starting the daemon, one types
telnet hostname portwhere hostname is the name of the machine running the daemon (one can use ``localhost'' if running on the local machine). The port is the port number in use by the daemon.
While the server is working on a task, the server is sensitive to interrupts. An interrupt will cause the server to abort the current task and begin listening for new instructions. The interrupt handling works about the same as in graphical mode when the user types Ctrl-C, though there is no confirmation prompt -- the task is always aborted. There may be a short delay before the interrupt is recognized.
Interrupts can be sent to the server by sending an interrupt (``INT'') to the process number of the server with the Unix kill command. The server socket will also raise an interrupt if out of band (OOB) data are received. Thus, the client can send a single arbitrary byte of OOB data to generate an interrupt. The Unix manual pages describe the concept of OOB data.
The default data mode for communications is ascii mode. In this mode, all data are transferred as ASCII text. Also available is binary mode, where data returned by the server is in a binary format, which can be more efficient for large data transfers.
The text expected by the daemon is in the form of statements which can be understood by the script interpreter, i.e., script lines. In addition, there are a number of special control commands. The modes implied by these commands apply to the current connection, and never carry over to subsequent connections. These commands consist of a single word from the table below:
The normal way to terminate a session with the server is to issue the close command, which will reset and clear the server and close the communication channel, and the server will begin listening for new connections. The ``reset and clear'' is equivalent to giving the reset and clear commands. If the keepall command was in effect, the server will not be reset and cleared before the connection is closed, thus its state will be retained for the next connection. If there is a communications error, the server is always reset and cleared, or will exit if dieonerror was in effect.
When a new connection is established, all of the modes associated with the commands assume the default values. These states do not carry over if keepall was given, so that the appropriate commands must be repeated to establish the same state.
There is quite a bit of internal server state that is not reset to any preset value between connections. Examples are the mode (physical or electrical) and the status of variables set with the !set command or Set function. Thus, when writing scripts for execution by the server, it is important to explicitly initialize any such state or variable.
All other input should be parsable by the script parser, except that lines that start with `#' are not allowed, so no comments or preprocessor directives are allowed.
After each line of input is given, the server returns a message giving the data type and possibly the data for each script command. Most script functions return some value. Assignments return the value assigned. A variable name returns the value of that variable, if the variable has a known type. The default mode is to return only the data type code, which minimizes the network overhead. Optionally, the longform command can be applied, in which case the data are returned. Note that this can be arbitrarily large for some data types.
If the XTNETDEBUG environment variable is set when Xic is started in server mode, a debugging mode is active, and Xic remains in the foreground. If the dumpmsg command is given, Xic will print the text of messages received on the terminal screen, enclosed in `|' symbols to delineate the text. The command nodumpmsg can be given to turn off the message printing. This can be a useful feature for debugging a client-side program which is communicating with Xic.
An example file xclient.cc is available which provides a demonstration of how to interact with the Xic daemon through a C/C++ program. This file can be found in the examples directory of the Xic installation.