- XPA_ACL
- If XPA_ACL is true, then
host-based XPA Access Control
is turned on and only specified machines can access specified access
points. If false, then access control is turned off and any
machine can access point. The default is turn turn access control on.
- XPA_ACLFILE
- If
XPA Access Control
is turned on, this variable specifies the name of the file containing
access control information for all access points started by this user.
The default file name is: $HOME/xpa.acl.
- XPA_DEFACL
- If
XPA Access Control
is turned on, this variable specifies the default access control
condition for all access points, if the XPA_ACLFILE file does
not exist. The default acl is: *:* $host +, meaning that
all processes on the host machine have full access to all access points.
- XPA_METHOD
-
Determines the socket connection method used by this session of XPA.
The choices are: inet (to use INET or Internet-based sockets)
and local (unix) (to use UNIX sockets). The default is
INET. Using the inet method will allow access from
other machines (subject to access controls) but using local will
not. Local is most useful for private access and when the machine in
question is not connected to the Internet.
Once defined, the first registration of an XPA access point will
ensure that an instance of the
XPA Name Server (xpans)
is running that handles that connection method. All new access points
will use the new connection method but existing access points will use
the original method.
- XPA_NSINET
- For the inet method of socket connection, this variable
specifies the host and port on which the
XPA Name Server (xpans)
is run. The default is *:*, meaning that the default XPA port
(14285) on the current machine is used. If several machines were all
accessing the same XPA access points, you would use this variable to
specify that they all use the same name server to find out about these
access points. For example, a value of bynars:* would mean
that the xpans name server is running on bynars and uses the default
port 12345. All machines would then get the XPA access points
registered with that name server, subject to access controls.
- XPA_NSUNIX
- For the local method of socket connection, this variable
specifies the name of the Unix file that will be used to access the
XPA Name Server (xpans). The default is
xpans_unix. This variable is not usually needed. Note that
is the local socket method is used, then remote machines will
not be able to access the xpans name server or the registered XPA access
points.
- XPA_NSUSERS
-
This variable specifies whether other users' access points will be
returned by the
XPA Name Server (xpans) for use by
xpaget, xpaset, etc.
Generally speaking, it is sufficient to run one xpans name server per
machine and register the access points for all users with that xpans.
This means, for example, that if you request information from
SAOtng by running:
xpaget SAOtng colormap
you might get information from your own SAOtng as well as
from another user running SAOtng on the same machine. The
XPA_NSUSERS variable controls whether you want such access
to the access points of other users.
By default, only your own access points are returned, so
that, in the example above, you would only get the colormap information
from the SAOtng you registered. If, however, you had set the value of the
XPA_NSUSERS variable to eric,fred, then you would be
able to communicate with both eric and fred's access points. Note that
this variable can be overridden using the -u switch on the
xpaget, xpaset, and xpainfo programs.
- XPA_MAXHOSTS
- The maximum number of access points that the programs
xpaset, xpaget, and xpainfo will
communicate with at one time. The default is 64, meaning, for
example, that the xpaset program will not send a message
to more than 100 access points at one time and xpaget will
not retrieve from more than 100 access points at one time.
- XPA_SHORT_TIMEOUT
- XPA is designed to allow data to be sent from one process to
another over a long period of time (i.e., a program that generates
image data sends that data to an image display, but slowly) but it
also seeks to prevent hangs. This is done by supporting 2 timeout
periods: a short timeout for protocol communication
and a long for data communication.
The XPA_SHORT_TIMEOUT variable
controls the short timeout and is used to prevent hangs
in cases where the XPA protocol requires internal communication between
the client and server that is controlled by the XPA interface
itself. Authentication is an example of this sort of communication,
as is the establishment of a data channel between the two processes.
The default value for the short is 30 seconds (which is
a pretty long time, actually). Setting the value to -1 will disable
short timeouts and allow an infinite amount of time.
- XPA_LONG_TIMEOUT
- XPA is designed to allow data to be sent from one process to
another over a long period of time (i.e., a program that generates
image data sends that data to an image display, but slowly) but it
also seeks to prevent hangs. This is done by supporting 2 timeout
periods: a short timeout for protocol communication
and a long for data communication.
The XPA_LONG_TIMEOUT variable controls the long
timeout and is used to prevent hangs in cases where communication
between the client and server that is not controlled by the
XPA interface itself. Transfer of data between client and server, or a
client's wait for a status message after completion of the server
callback, are two examples of this sort of communication. By default,
the long timeout is set to 180 seconds.
Setting the value to -1 will disable long timeouts and allow
an infinite amount of time.
- XPA_TMPDIR
- This variable specifies the directory into which XPA logs, Unix
socket files (when XPA_METHOD is local), etc. are
stored. The default is /tmp/.xpa.
- XPA_SIGUSR1
- If the value of this variable is true, then XPA will
catch SIGUSR1 signals when performing an I/O operation in order to
curtail that operation. This facility allows users to send a SIGUSR1
signal to an XPA server if a client is hanging up the server by
sending or receiving data too slowly (timeouts also can be used -- see
above). When enabled in this way, the SIGUSR1 signal is ignored at all other
times, so that its safe to send the signal at any time. If the
variable is set to false, then SIGUSR1 is not used at
all. Turning off SIGUSR1 would be desired in cases there the program
uses SIGUSR1 for some other reason and does not want XPA interfering.
The default is to use the signal.
- XPA_VERBOSITY
- Specify the verbosity level of error messages. If the value is
set to 0, false, or off, then no error
messages are printed to stderr. If the value is 1, then
important XPA error messages will be output. If the value is
set to 2, XPA warnings about out-of-sync messages will also
be output. These latter almost always can be ignored.