Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.astro.louisville.edu/software/sbig/archive/xmccd-4.1/xmccd-4.1e/xpa-2.1.14/doc/xpa.ps Äàòà èçìåíåíèÿ: Fri Jun 8 07:13:30 2012 Äàòà èíäåêñèðîâàíèÿ: Thu Feb 27 22:30:12 2014 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: m 5

XPA: Public Access to Data and Algorithms
Summary
This document is the Table of Contents for XPA.
Description
The XPA messaging system provides seamless communication between many kinds of Unix
programs, including X programs and Tcl/Tk programs. It also provides an easy way for users to
communicate with XPA­enabled programs by executing XPA client commands in the shell or by
utilizing such commands in scripts. Because XPA works both at the programming level and the shell
level, it is a powerful tool for unifying any analysis environment: users and programmers have great
flexibility in choosing the best level or levels at which to access XPA services, and client access can
be extended or modified easily at any time.
A program becomes an XPA­enabled server by defining named points of public access through
which data and commands can be exchanged with other client programs (and users). Using standard
TCP sockets as a transport mechanism, XPA supports both single­point and broadcast messaging to
and from these servers. It supports direct communication between clients and servers, or indirect
communication via an intermediate message bus emulation program. Host­based access control is
implemented, as is as the ability to communicate with XPA servers across a network.
XPA implements a layered interface that is designed to be useful both to software developers and to
users. The interface consists of a library of XPA client and server routines for use in C/C++ programs
and a suite of high­level user programs built on top of these libraries. Using the XPA library, access
points can be added to Tcl/Tk programs, Xt programs, or to Unix programs that use the XPA event
loop or any event loop based on select(). Client access subroutines can be added to any Tcl/Tk, Xt, or
Unix program. Client access also is supported at the command line via a suite of high­level programs.
Choose from the following topics:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Introduction to XPA
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Access Point Names and Templates
.
.
.
.
.
.
.
.
.
. 5
Getting Common Information About Access Points
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Communication Methods
.
.
.
.
.
.
.
.
.
.
.
.
.
. 10
Communication Between Hosts
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 14
Distinguishing Users
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 15
XPA User Programs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 16
xpaget: get data and info
.
.
.
.
.
.
.
.
.
.
.
.
.
. 15
xpaset: send data and info
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 16
xpainfo: send info alert
.
.
.
.
.
.
.
.
.
.
.
.
. 17
xpaaccess: get access point info
.
.
.
.
.
.
.
.
.
.
.
.
. 19
xpamb: message bus emulation
.
.
.
.
.
.
.
.
.
.
.
.
.
. 22
xpans: the XPA name server
1

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 25
XPA Server Routines
.
.
.
.
.
.
.
.
.
.
.
.
. 26
XPANew: define a new access point
.
.
.
.
.
.
.
.
.
. 29
XPACmdNew: define a new command access point
.
.
.
.
.
.
.
.
.
.
.
.
.
. 30
XPACmdAdd: add a command
.
.
.
.
.
.
.
.
.
.
.
.
.
. 30
XPACmdDel: delete a command
.
.
.
.
.
.
.
.
.
.
.
. 31
XPAInfoNew: define an info access point
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 32
XPAFree: free an access point
.
.
.
.
.
.
.
.
.
.
.
. 32
XPAMainLoop: event loop for select server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 33
XPAPoll: poll for XPA events
.
.
.
.
.
.
.
.
.
.
. 34
XPACleanup: release reserved XPA memory
.
.
.
.
.
.
.
.
.
. 34
XPA Server Macros: accessing structure internals
.
.
.
.
.
.
.
.
.
.
.
. 35
XPA Race Conditions: how to avoid them
.
.
.
.
.
.
.
.
.
.
.
.
. 37
XPA Out of Memory (OOM) errors
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 38
XPA Client Routines
.
.
.
.
.
.
.
.
.
.
. 46
XPAOpen: open a persistent client connection
.
.
.
.
.
.
.
.
.
.
. 46
XPAClose: close persistent client connection
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
XPAGet: get data
.
.
.
.
.
.
.
.
.
.
.
.
.
. 40
XPASet: send data or commands
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 42
XPAInfo: send an info alert
.
.
.
.
.
.
.
.
.
.
.
.
. 43
XPAGetFd: get data and write to an fd
.
.
.
.
.
.
.
.
.
.
.
. 44
XPASetFd: read data from and fd and send
.
.
.
.
.
.
.
.
.
.
.
. 47
XPANSLookup: look up an access point
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 48
XPAAccess: get access info
.
.
.
.
.
.
.
.
.
.
.
. 50
The XPA/Xt Interface: Xt interface to XPA
.
.
.
.
.
.
.
.
.
.
. 51
The XPA/Tcl Interface: Tcl interface to XPA
Tailoring the XPA Environment
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 55
Environment Variables
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 61
Access Control
Miscellaneous
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 63
XPA ChangeLog
.
.
.
.
.
.
.
.
.
.
.
.
.
. 75
Where to Find Example/Test Code
.
.
.
.
.
.
.
.
.
.
.
. 76
User Changes Between XPA 1.0 and 2.0
.
.
.
.
.
.
.
.
.
.
.
. 77
API Changes Between XPA 1.0 and 2.0
.
.
.
.
.
.
.
.
.
.
.
.
. 80
What Does XPA Stand For, Anyway?
Last updated: September 10, 2003
2

XPAIntro: Introduction to the XPA Messaging System
Summary
A brief introduction to the XPA messaging system, which provides seamless communication between all
kinds of Unix event­driven programs, including X programs, Tcl/Tk programs, and Perl programs.
Description
The XPA messaging system provides seamless communication between all kinds of Unix programs,
including X programs, Tcl/Tk programs, and Perl programs. It also provides an easy way for users to
communicate with these XPA­enabled programs by executing XPA client commands in the shell or by
utilizing such commands in scripts. Because XPA works both at the programming level and the shell level,
it is a powerful tool for unifying any analysis environment: users and programmers have great flexibility
in choosing the best level or levels at which to access XPA services, and client access can be extended or
modified easily at any time.
A program becomes an XPA­enabled server by defining named points of public access through which data
and commands can be exchanged with other client programs (and users). Using standard TCP sockets as a
transport mechanism, XPA supports both single­point and broadcast messaging to and from these servers.
It supports direct communication between clients and servers, or indirect communication via an
intermediate message bus emulation program. Host­based access control is implemented, as is as the
ability to communicate with XPA servers across a network.
XPA implements a layered interface that is designed to be useful both to software developers and to users.
The interface consists of a library of XPA client and server routines for use in programs and a suite of
high­level user programs built on top of these libraries. Using the XPA library, access points can be added
to Tcl/Tk programs, Xt programs, or to Unix programs that use the XPA event loop or any event loop
based on select(). Client access subroutines can be added to any Tcl/Tk or Unix program. Client access
also is supported at the command line via a suite of high­level programs.
The major components of the XPA layered interface are:
A set of XPA server routines, centered on XPANew(), which are used by XPA server programs to tag
public access points with string identifiers and to register send and receive callbacks for these access
points.
A set of XPA client routines, centered on the XPASet() and XPAGet(), which are used by external
client applications to exchange data and commands with an XPA server.
High­level programs, centered on xpaset and xpaget, which allow data and information to be
exchanged with XPA server programs from the command line and from scripts. These programs have
the command syntax:
[data] | xpaset [qualifiers ...]
xpaget [qualifiers ...]
An XPA name server program, xpans, through which XPA access point names are registered by
servers and distributed to clients.
1

Defining an XPA access point is easy: a server application calls XPANew(), XPACmdNew(), or the
experimental XPAInfoNew() routine to create a named public access point. An XPA service can specify
"send" and "receive" callback procedures (or an "info" procedure in the case of XPAInfoNew()) to be
executed by the program when an external process either sends data or commands to this access point or
requests data or information from this access point. Either of the callbacks can be omitted, so that a
particular access point can be specified as read­only, read­write, or write­only. Application­specific client
data can be associated with these callbacks. Having defined one or more public access points in this way,
an XPA server program enters its usual event loop (or uses the standard XPA event loop).
Clients communicate with these XPA public access points using programs such as xpaget, xpaset, and
xpainfo (at the command line), or routines such as XPAGet(), XPASet(), and XPAInfo() within a program.
Both methods require specification of the name of the access point. The xpaget program returns data or
other information from an XPA server to its standard output, while the xpaset program sends data or
commands from its standard input to an XPA application. The corresponding API routines set/get data
to/from memory, returning error messages and other info as needed. If a template is used to specify the
access point name (e.g., "ds9*"), then communication will take place with all servers matching that
template.
Please note that XPA currently is not thread­safe. All XPA calls must be in the same thread.
Go to XPA Help Index
Last updated: March 10, 2007
2

XPATemplate: Access Point Names and Templates
Summary
XPA access points are composed of two parts: a general class and a specific name. Both parts accept
template characters so that you can send/retrieve data to/from multiple servers at one time.
Description
When XPA servers call XPANew(), or XPACmdNew() to define XPA access points, they specify a string
identifier composed of a class and a name. When clients communicate with XPA access points, they
specify which access points to communicate with using an identifier of the form:
class:name
All registered XPA access points that match the specified identifier will be available for communication
(subject to access control rules, etc.)
As of XPA 2.1.5, the length of both the class and name designations are limited to 1024 characters.
The XPA class:name identifier actually is a template: it accepts wild cards in its syntax, so a single
specifier can match more than one XPA access point. (Note that the class is optional and defaults to "*".)
The allowed syntax for clients to specify the class:name template is of the form shown below. (Note that
"*" is used to denote a generic wild card, but other wild cards characters are supported, as described
below).
template explanation
­­­­­­­­ ­­­­­­­­­­­
class:name exact match of class and name
name match any class with this name
*:name match any class with this name
class:* match any name of this class
*:* match any access point
In general, the following wild­cards can be applied to class and name:
wildcard explanation
­­­­­­­­ ­­­­­­­­­­­
? match any character, but there must be one
* match anything, or nothing
[...] match an inclusive set
Although the class:name template normally is used to refer to XPA access points, these also can be
specified using their individual socket identifiers. For inet sockets, the socket identifier is ip:port, where
ip can be the DNS­registered name, the ASCII IP number (e.g. 123.45.67.890) or the hex IP number (e.g.
838f3a60). For unix sockets, the identifier is the socket file name. These socket identifiers are displayed
as the fourth argument in the xpans display of registered access points. For example, consider the ds9
program started using inet sockets. The xpans name server will register something like this:
3

csh> xpaget xpans
DS9 ds9 gs saord.harvard.edu:3236 eric
You can access ds9 using ip:3236 in any of the three forms:
csh> xpaget saord:3236 file
/home/eric/data/snr.ev
csh> xpaget 123.45.67.890:3236 file
/home/eric/data/snr.ev
csh> xpaget 838f3a60:3236 file
/home/eric/data/snr.ev
In the case of unix sockets, the socket identifier is a file:
csh> xpaget xpans
DS9 ds9 gs /tmp/.xpa/DS9_ds9.2631 eric
csh> xpaget /tmp/.xpa/DS9_ds9.2631 file
/home/eric/data/snr.ev
This feature can be useful in distinguishing between multiple instances of a program that all have the same
class:name designation.
Go to XPA Help Index
Last updated: September 10, 2003
4

XPACommon: Getting Common Information About Access
Points
Summary
There are various kinds of generic information you can retrieve about an XPA access point by using the
xpaget command.
Description
You can find out which XPA access points have been registered with the currently running XPA name
server by executing the xpaget command to retrieve info from the XPA name server:
xpaget xpans
If, for example, the stest test server program is running, the following XPA access points will be returned
(the specifics of the returned info will vary for different machines and users):
XPA xpa gs 838e2f67:1262 eric
XPA xpa1 gs 838e2f67:1266 eric
XPA c_xpa gs 838e2f67:1267 eric
XPA i_xpa i 838e2f67:1268 eric
Note that access to this information is subject to the usual XPA Access Control restrictions.
Each XPA access point supports a number of reserved sub­commands that provide access to different
kinds of information, e.g. the access control for that access point. These sub­commands can be executed
by using xpaset or xpaget at the command line, or XPAGet() or XPASet() in programs, e.g:
xpaget ds9 ­acl
xpaget ds9 ­help
xpaget ds9 env FOO
xpaset ­p ds9 env FOO foofoo
With the exception of ­help and ­version, reserved sub­commands are available only on the machine on
which the XPA server itself is running. The following reserved sub­commands are defined for all access
points:
­acl get (set) the access control list [options: host type acl, for set]
The 'xpaset' option allows you to add a new acl for a given host, or change the acl for an existing
host. See XPA Access Control for more information. This access point is available only on the server
machine.
­env get (set) an environment variable [options: name (value, for set)]
The 'xpaget' option will return the value of the named environment variable. The 'xpaset' option will
set the value of the names variable to the specified value. This access point is available only on the
server machine. (Please be advised that we have had problems setting environment variables in static
5

Tcl/Tk programs such as ds9 running under Linux.)
­clipboard set(get) information on a named clipboard
Clients can store ASCII state information on any number of named clipboards. Clipboards of the
same name created by clients on different machines are kept separate. The syntax for creating a
clipboard is:
[data] | xpaset [server] ­clipboard add|append [clipboard_name]
xpaset ­p [server] ­clipboard delete [clipboard_name]
Use "add" to create a new clipboard or replace the contents of an existing one. Use "append" to
append to an existing clipboard.
Information on a named clipboard is retrieved using:
xpaget [server] ­clipboard [clipboard_name]
­exec set: execute commands from buffer [options: none]
If ­exec is specified in the paramlist of an 'xpaset' call, then further sub­commands will be retrieved
from the data buffer.
­help get: return help string for this XPA or sub­command [options: name (for sub­commands)]
Each XPA access point and each XPA sub­command can have a help string associated with it that is
specified when the access point is defined. The ­help option will return this help string. For XPA
access points that contain user­defined sub­commands, you can get the help string for a particular
sub­command by specifying its name, or else get the help strings for all sub­commands if not name is
specified.
­ltimeout get (set) the long timeout value [options: seconds|reset]
The 'xpaget' option will return the value of the long timeout (in seconds). The 'xpaset' option will set
the value of the long timeout. If "reset" is specified, then the timeout value will be reset to the default
value.
­nsconnect set: re­establish name server connection to all XPA's [options: none]
If the XPA Name Server (xpans) process has terminated unexpectedly and then re­started, this
sub­command can be used to re­establish the connection. You use it by sending the command to the
[name:port] or [file] of the access point instead of to the XPA name (since the latter requires the
xpans connection!):
xpaset ­p 838e2f67:1268 ­nsconnect
See xpans for more information.
­nsdisconnect set: break name server connection to all XPA's [options: none]
This sub­command will terminate the connection to the XPA Name Server (xpans), thereby making
all access points inaccessible except through their underlying [name:port] or [file] identifiers. I forget
why we added it, it seems pretty useless.
6

­stimeout get (set) the short timeout value [options: seconds|reset]
The 'xpaget' option will return the value of the short timeout (in seconds). The 'xpaset' option will
set the value of the short timeout. If "reset" is specified, then the timeout value will be reset to the
default value.
­remote set: register xpa with remote server [options: host[:port] [acl]] [­proxy]
This sub­command will register the XPA access point with the XPA name server (xpans) on the
specified host (which must already be running). The specified host also is given access control to the
access point, using the specified acl or the default acl of "+" (meaning the remote host can xpaset,
xpaget, xpainfo or xpaaccess). If the acl is specified as "­", then the access point is unregistered. See
Communication Between Machines for more information on how this sub­command is used.
­version get: return XPA version string [options: none]
The version refers to the version of XPA used to define this access point (currently something like
2.0).
You can add your own reserved commands to all XPA access points by using the XPACmdAdd() routine,
passing the XPA handle returned by XPA XPAGetReserved(void) as the first argument. Note again that
these will only be available on the machine where the XPA service is running.
Go to XPA Help Index
Last updated: September 10, 2003
7

XPAMethod: XPA Communication Methods
Summary
XPA supports both inet and unix (local) socket communication.
Description
XPA uses sockets for communication between processes. It supports three methods of socket
communication: inet, localhost, and unix. In general, the same method should be employed for all XPA
processes in a session and the global environment variable XPA_METHOD should be used to set up the
desired method. By default, the preferred method is "inet", which is appropriate for most users. You can
set up a different method by typing something like:
setenv XPA_METHOD local # unix csh
XPA_METHOD=local; export XPA_METHOD # unix sh, bash, windows/cygwin
set XPA_METHOD=localhost # dos/windows
The options for XPA_METHOD are: inet, unix (or local), and localhost. On Unix machines, this
environment setup command can be placed in your shell init file (.cshrc, .profile, .bashrc, etc.) On
Windows platforms, it can be placed in your AUTOEXEC.BAT file (I think!).
By default, inet sockets are used by XPA. These are the standard Internet sockets that are used by
programs such as Netscape, ftp. etc. Inet sockets utilize the IP address of the given machine and a (usually
random) port number to communicate between processes on the same machine or between different
machines on the Internet. (Note that XPA has an Access Control mechanism to prevent unauthorized
access of XPA access points by other computers on the Net). For users connected to the Internet, this
usually is the appropriate communication method. For more information about setting up XPA
communication between machines, see Communication Between Machines.
In you are using XPA on a machine without an Internet connection, then inet sockets are not appropriate.
In fact, an XPA process often will hang for many seconds while waiting for a response from the Domain
Name Service (DNS) when using inet sockets. Instead of inet sockets, users on Unix platforms can also
use unix sockets (also known as local sockets). These sockets are based on the local file system and do not
make use of the DNS. They generally are considered to be faster than inet sockets, but they are not
implemented under Windows. Use local sockets as a first resort if you are on a Unix machine that is not
connected to the Internet.
Users not connected to the Internet also can use localhost sockets. These are also inet­type sockets but the
IP address used for the local machine is the localhost address, 0x7F000001, instead of the real IP of the
machine. Depending on how sockets are set up for a given platform, communication with the DNS usually
is not required in this case (though of course, XPA cannot interact with other machines). The localhost
method will generally work on both Unix and Windows platforms, but whether the DNS is required or not
is subject to individual configurations.
8

A final warning/reminder: if your XPA­enabled server hangs at startup time and your XPA_METHOD is
inet, the problem probably is related to an incorrect Internet configuration. This can be confirmed by using
the unix method or (usually) the localhost method. You can use these alternate methods if other hosts do
not need access to the XPA server.
Go to XPA Help Index
Last updated: September 10, 2003
9

XPAInet: XPA Communication Between Hosts
Summary
XPA uses standard inet sockets to support communication between two or more host computers.
Description
When the Communication Method is set to inet (as it is by default), XPA can be used to communicate
between different computers on the Internet. INET sockets utilize the IP address of the given machine and
a (usually random) port number to communicate between processes on the same machine or between
different machines on the Internet. These standard Internet sockets are also used by programs such as
Netscape, ftp. etc.
XPA supports a host­based Access Control mechanism to prevent unauthorized access of XPA access
points by other computers on the Net. By default, only the machine on which the XPA server is running
can access XPA services. Therefore, setting up communication between a local XPA server machine and a
remote client machine requires a two­part registration process:
the XPA service on the local machine must be made known to the remote machine
the remote machine must be given permission to access the local XPA service
Three methods by which this remote registration can be accomplished are described below.
Manual Registration
The first method is the most basic and does not require the remote client to have xpans running. To use it,
the local server simply gives a remote client machine access to one or more XPA access points using
xpaset and the ­acl sub­command. For example, consider the XPA test program "stest" running on a local
machine. By default the access control for the access point named "xpa" is restricted to that machine:
[sh]$ xpaget xpa ­acl
*:* 123.456.78.910 gisa
*:* localhost gisa
Using xpaset and the ­acl sub­command, a remote client machine can be given permission to perform
xpaget, xpaset, xpaaccess, or xpainfo operations. For example, to allow the xpaget operation, the
following command can be issued on the local machine:
[sh]$ xpaset ­p xpa ­acl "remote_machine g"
This results in the following access permissions on the local machine:
[sh]$ xpaget xpa ­acl
XPA:xpa 234.567.89.012 g
*:* 123.456.78.910 gisa
*:* localhost gisa
10

The remote client can now use the local server's xpans name server to establish communication with the
local XPA service. This can be done on a call­by­call basis using the ­i switch on xpaset, xpaget, etc:
[sh]$ xpaget ­i "local_machine:12345" xpa
class: XPA
name: xpa
method: 88877766:2778
sendian: little
cendian: big
Alternatively, the XPA_NSINET variable on the remote machine can be set to point directly to xpans on
the local machine, removing the need to override this value each time an XPA program is run:
[csh]$ setenv XPA_NSINET 'karapet:$port'
[csh]$ xpaget xpa
class: XPA
name: xpa
method: 88877766:2778
sendian: little
cendian: big
Here, '$port' means to use the default XPA name service port (14285). not a port environment variable.
Access permission for remote client machines can be stored in a file on the local machine pointed to by the
XPA_ACLFILE environment variable or using the XPA_DEFACL environment variable. See XPA
Access Control for more information.
Remote Registration
If xpans is running on the remote client machine, then a local xpaset command can be used with the
­remote sub­command to register the local XPA service in the remote name service, while at the same
time giving the remote machine permission to access the local service. For example, assume again that
"stest" is running on the local machine and that xpans is also running on the remote machine. To register
access of this local xpa on the remote machine, use the xpaset and the ­remote sub­command:
[sh]$ ./xpaset ­p xpa ­remote 'remote_machine:$port' +
To register the local xpa access point on the remote machine with xpaget access only, execute:
[sh]$ ./xpaset ­p xpa ­remote 'remote_machine:$port' g
Once the remote registration command is executed, the remote client machine will have an entry such as
the following in its own xpans name service:
[csh]$ xpaget xpans
XPA xpa gs 88877766:2839 eric
The xpa access point can now be utilized on the remote machine without further setup:
11

[csh]$ xpaget xpa
class: XPA
name: xpa
method: 838e2f68:2839
sendian: little
cendian: big
To unregister remote access from the local machine, use the same command but with a '­' argument:
[sh]$ xpaset ­p xpa ­remote 'remote_machine:$port' ­
The benefit of using remote registration is that communication with remote access points can be mixed
with that of other access points on the remote machine. Using Access Point Names and Templates, one
XPA command can be used to send or receive messages to the remote and local services.
XPANS Proxy Registration
The two methods described above are useful when the local and remote machines are able to communicate
freely to one another. This would be the case on most Local Area Networks (LANs) where all machines
are behind the same firewall and there is no port blocking between machines on the same LAN. The
situation is more complicated when the XPA server is behind a firewall, where outgoing connections are
allowed, but incoming port blocking is implemented to prevent machines outside the firewall from
connecting to machines inside the firewall. Such incoming port blocking will prevent xpaset and xpaget
from connecting to an XPA server inside a firewall.
To allow locally fire­walled XPA services to register with remote machines, we have implemented a
proxy service within the xpans name server. To register remote proxy service, xpaset and the ­remote
sub­command is again used, but with an additional ­proxy argument added to the end of the command:
[sh]$ ./xpaset ­p xpa ­remote 'remote_machine:$port' g ­proxy
Once a remote proxy registration command is executed, the remote machine will have an entry such as the
following in its own xpans name service:
[csh]$ xpaget xpans
XPA xpa gs @88877766:2839 eric
The '@' sign in the name service entry indicates that xpans proxy processing is being used for this access
point. Other than that, from the user's point of view, there is no difference in how this XPA access point is
contacted using XPA programs (xpaset, xpaget, etc.) or libraries:
[csh]$ xpaget xpa
class: XPA
name: xpa
method: 88877766:3053
sendian: little
cendian: big
Of course, the underlying processing of the XPA requests is very much different when xpans proxy is
involved. Instead of an XPA program such contacting the XPA service directly, it contacts the local xpans.
Acting as a proxy server, xpans communicates with the XPA service using the command channel
established at registration time. Commands (including establishing a new data channel) are sent between
12

xpans and the XPA service to set up a new message transfer, and then data is fed to/from the xpa request,
through xpans, from/to the XPA service. In this way, it can be arranged so that connections between the
fire­walled XPA service and the remote client are always initiated by the XPA service itself. Thus,
incoming connections that would be blocked by the firewall are avoided. Note that there is a performance
penalty for using the xpans/proxy service. Aside from extra overhead to set up proxy communication, all
data must be sent through the intermediate proxy process.
The xpans proxy scheme requires that the remote client allow the local XPA server machine to connect to
the remote xpans/proxy server. If the remote client machine also is behind a port­blocking firewall, such
connections will be disallowed. In this case, the only solution is to open up some ports on the remote client
machine to allow incoming connections to xpans/proxy. Two ports must be opened (for command and
data channel connections). By default, these two ports are 14285 and 14287. The port numbers can be
changed using the XPA_NSINET environment variable. This variable takes the form:
setenv XPA_NSINET machine:port1[,port2[,port3]]
where port1 is the main connecting port, port2 is the XPA access port, and port3 is the secondary data
connecting port. The second and third ports are optional and default to port1+1 and port1+2, respectively.
It is port1 and port3 that must be left open for incoming connections.
For example, to change the port assignments so that xpans listens for registration commands on port 12345
and data commands on port 28573:
setenv XPA_NSINET myhost:12345
Alternatively, all three ports can be assigned explicitly:
setenv XPA_NSINET remote:12345,3000,12346
In this case 12345 and 12346 should be open for incoming connections. The XPA access port (which need
not be open to the outside world) is set to 3000.
Finally, note that we currently have no mechanism to cope with Internet proxy servers (such as SOCKS
servers). If an XPA service is running on a machine that cannot connect directly to outside machines, but
goes through a proxy server instead, there currently is no way to register that XPA service with a remote
machine. We hope to implement support for SOCKS proxy in a future release.
Go to XPA Help Index
Last updated: September 10, 2003
13

XPAUsers: Distinguishing Users
Summary
XPA normally distinguishes between users on a given host, but it is possible to send data to access points
belonging to other users.
Description
A single XPA name service typically serves all users on a given machine. Two users can register the same
XPA access points on the same machine without conflict, because the user's username is registered with
each access point and, by default, programs such as xpaget and xpaset only process access points of the
appropriate user. For example:
XPA xpa1 gs 838e2f67:1262 eric
XPA xpa2 gs 838e2f67:1266 eric
XPA xpa1 gs 838e2f67:2523 john
XPA xpa2 gs 838e2f67:2527 john
Here the users "eric" and "john" both have registered the access points xpa1 and xpa2. When either "john"
or "eric" retrieves information from xpa1, they will process only the access point registered in their user
name.
If you want to access another user's XPA access points on a single machine, use the ­u [user] option on
xpaset, xpaget, etc. For example, if eric executes:
xpaget ­u john xpa1
he will access John's xpa1 access point.Use "*" to access all users on a given machine:
xpaget ­u "*" xpa1
Note that the XPA Environment Variable XPA_NSUSERS can be used to specify the default list of users
to process:
setenv XPA_NSUSERS "eric,john"
will cause access points from both "eric" and "john" to be processed by default.
Go to XPA Help Index
Last updated: September 10, 2003
14

XPA Programs
Summary
Use the XPA programs to send/receive data to/from XPA servers from the command line or from scripts.
| xpaset [­h] [­i nsinet] [­m method] [­n] [­p] [­s] [­t sval,lval] [­u users] [­v]