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
xpa(7) SAORD Documentation xpa(7) NAME
XPA - Public Access to Data and Algorithms SYNOPSIS
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 mes- saging to and from these servers. It supports direct communication between clients and servers, or indirect communication via an interme- diate 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: o Introduction to XPA [xpaintro(7)] o Access Point Names and Templates [xpatemplate(7)] o Getting Common Information About Access Points [xpacommon(7)] o Communication Methods [xpamethod(7)] o Communication Between Hosts [xpainet(7)] o Distinguishing Users [xpausers(7)] o XPA User Programs o xpaget: get data and info [xpaget(1)] o xpaset: send data and info [xpaset(1)] o xpainfo: send info alert [xpainfo(1)] o xpaaccess: get access point info [xpaaccess(1)] o xpamb: message bus emulation [xpamb(1)] o xpans: the XPA name server [xpans(1)] o XPA Server Routines o XPANew: define a new access point [xpanew(3)] o XPACmdNew: define a new command access point [xpacmdnew(3)] o XPACmdAdd: add a command [xpacmdadd(3)] o XPACmdDel: delete a command [xpacmddel(3)] o XPAInfoNew: define an info access point [xpainfonew(3)] o XPAFree: free an access point [xpafree(3)] o XPAMainLoop: event loop for select server [xpamainloop(3)] o XPAPoll: poll for XPA events [xpapoll(3)] o XPACleanup: release reserved XPA memory [xpacleanup(3)] o XPA Server Macros: accessing structure internals [xpamacros(3)] o XPA Race Conditions: how to avoid them [xparace(3)] o XPA Out of Memory (OOM) errors [xpaoom(3)] o XPA Client Routines o XPAOpen: open a persistent client connection [xpaopen(3)] o XPAClose: close persistent client connection [xpaclose(3)] o XPAGet: get data [xpaget(3)] o XPASet: send data or commands [xpaset(3)] o XPAInfo: send an info alert [xpainfo(3)] o XPAGetFd: get data and write to an fd [xpagetfd(3)] o XPASetFd: read data from and fd and send [xpasetfd(3)] o XPANSLookup: look up an access point [xpanslookup(3)] o XPAAccess: get access info [xpaaccess(3)] o The XPA/Xt Interface: Xt interface to XPA [xpaxt(7)] o The XPA/Tcl Interface: Tcl interface to XPA [xpa(3tcl)] o Tailoring the XPA Environment o Environment Variables [xpaenv(7)] o Access Control [xpaacl(7)] o Miscellaneous o Where to Find Example/Test Code o User Changes Between XPA 1.0 and 2.0 o API Changes Between XPA 1.0 and 2.0 o What Does XPA Stand For, Anyway? version 2.1.14 June 7, 2012 xpa(7)