xpamethod(7) [debian man page]
xpamethod(7) SAORD Documentation xpamethod(7) NAME
XPAMethod - XPA Communication Methods SYNOPSIS
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 gen- eral, 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 plat- form, 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. 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. SEE ALSO
See xpa(7) for a list of XPA help pages version 2.1.14 June 7, 2012 xpamethod(7)
Check Out this Related Man Page
xpainet(7) SAORD Documentation xpainet(7) NAME
XPAInet - XPA Communication Between Hosts SYNOPSIS
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 Net- scape, 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: o the XPA service on the local machine must be made known to the remote machine o 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 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 vari- able or using the XPA_DEFACL environment variable. See <A HREF="./acl.html">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: [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 incom- ing 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 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 environ- ment 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 con- nections. 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 regis- ter that XPA service with a remote machine. We hope to implement support for SOCKS proxy in a future release. SEE ALSO
See xpa(7) for a list of XPA help pages version 2.1.14 June 7, 2012 xpainet(7)