The XPA Environment

The following environment variables can be used to tailor the overall XPA environment:

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.

Index to the XPA Help Pages

Last updated: May 18, 1999