In image display applications the new driver is used by an IRAF task to connect to the image display server through any one of several transport methods. The initial set of supported communications methods are Internet sockets, Unix domain sockets, and FIFO pipes. Unless overridden a connection is first attempted using Unix domain sockets; if this fails the familiar old /dev FIFO pipes are used. The domain socket name is formed using the user's userid so each user gets his/her own private network socket and conflicts between users doing image display on the same host are automatically avoided. For accessing remote display servers TCP/IP sockets may be used to connect to any host on the Internet. (Don't confuse this with the X11 display connection, which occurs at a different level).
To override this connection scheme, e.g., to use private FIFO pipes or Internet sockets, users can define a host level environment variable `IMTDEV' that specifies the domain and address of the desired connection. The form of the address depends upon the domain, as illustrated in the examples below:
inet:5187 Server connection to TCP/IP port 5187 on the
local host. For a client, a connection to the
given port on the local host.
inet:5187:foo.bar.edu Client connection to TCP/IP port 5187 on
Internet host foo.bar.edu. The numeric form
of address may also be used.
unix:/tmp/.IMT%d Unix domain socket with the given pathname,
local host only. Any "%d" fields, if present,
are replaced by the user's UID number.
fifo:/dev/imt1i:/dev/imt1o FIFO or named pipes with the given pathnames.
IPC method, local host only. Two pathnames are
required, one for input and one for output,
since FIFOs are not bidirectional. For a
client the first FIFO listed will be the
client's input FIFO; for a server the first
FIFO will be the server's output FIFO. This
allows the same address to be used for both
the client and the server, as for the other
domains.
Note that by defining IMTDEV to name a personal set of FIFO pipes
it is no longer necessary for users to have personal graphcap files, however,
personal graphcap files are another way to override the default connection
scheme. In V2.10.3BETA the `DD' strings of the stdimage devices were
changed so the "/dev/imt1" pipe was removed leaving an entry that looks
like the following:
imt1|imt512|imtool|Imtool display server:\ :cn#1:LC:BS@:z0#1:zr#200:DD=node!imtool,,512,512:tc=iism70:Users who still have personal graphcap files will still be able to use them since specifying a pipe will use that as the connection, alternatively, using the domain address syntax will also define a connection type. For example the DD strings
:DD=node!imtool,inet\:5187,512,512:tc=iism70:
:DD=node!imtool,inet\:5187\:foo.bar.edu,512,512:tc=iism70:
:DD=node!imtool,unix\:/tmp/.IMT%d,512,512:tc=iism70:
define the same connection request as the IMTDEV definition above. Note that
the `:' must be escaped with a backslash to avoid terminating the graphcap
entry prematurely.
In this way users can specify a stdimage device that is a
display server running on some other node, or one that uses a different type
of input (as when there are two ximtool / SAOimage windows running
simultaneously).The accompanying article on Hints... has other examples of how the display connections can be established. Users with questions about how to set up a particular configuration should feel free to contact IRAF site support.
Doug Tody, Mike Fitzpatrick
This document was translated by ms2html v1.8 on 21Jan95.