1xpainet(n) SAORD Documentation xpainet(n)
2
6 XPAInet: XPA Communication Between Hosts
7
9 XPA uses standard inet sockets to support communication between two or
10 more host computers.
11
13 When the Communication Method is set to inet (as it is by default), XPA
14 can be used to communicate between different computers on the Internet.
15 INET sockets utilize the IP address of the given machine and a (usually
16 random) port number to communicate between processes on the same
17 machine or between different machines on the Internet. These standard
18 Internet sockets are also used by programs such as Netscape, ftp. etc.
19 XPA supports a host-based Access Control mechanism to prevent unautho‐
21 rized access of XPA access points by other computers on the Net. By
22 default, only the machine on which the XPA server is running can access
23 XPA services. Therefore, setting up communication between a local XPA
24 server machine and a remote client machine requires a two-part regis‐
25 tration process:
26 · the XPA service on the local machine must be made known to the
28 remote machine
29 · the remote machine must be given permission to access the local XPA
31 service
32 Three methods by which this remote registration can be accomplished are
34 described below.
35 Manual Registration
37 The first method is the most basic and does not require the remote
39 client to have xpans running. To use it, the local server simply gives
40 a remote client machine access to one or more XPA access points using
41 xpaset and the -acl sub-command. For example, consider the XPA test
42 program "stest" running on a local machine. By default the access con‐
43 trol for the access point named "xpa" is restricted to that machine:
44 [sh]$ xpaget xpa -acl
46 *:* 123.456.78.910 gisa
47 *:* localhost gisa
48 Using xpaset and the -acl sub-command, a remote client machine can be
50 given permission to perform xpaget, xpaset, xpaaccess, or xpainfo oper‐
51 ations. For example, to allow the xpaget operation, the following com‐
52 mand can be issued on the local machine:
53 [sh]$ xpaset -p xpa -acl "remote_machine g"
55 This results in the following access permissions on the local machine:
57 [sh]$ xpaget xpa -acl
59 XPA:xpa 234.567.89.012 g
60 *:* 123.456.78.910 gisa
61 *:* localhost gisa
62 The remote client can now use the local server's xpans name server to
64 establish communication with the local XPA service. This can be done on
65 a call-by-call basis using the -i switch on xpaset, xpaget, etc:
66 [sh]$ xpaget -i "local_machine:12345" xpa
68 class: XPA
69 name: xpa
70 method: 88877766:2778
71 sendian: little
72 cendian: big
73 Alternatively, the XPA_NSINET variable on the remote machine can be set
75 to point directly to xpans on the local machine, removing the need to
76 override this value each time an XPA program is run:
77 [csh]$ setenv XPA_NSINET 'karapet:$port'
79 [csh]$ xpaget xpa
80 class: XPA
81 name: xpa
82 method: 88877766:2778
83 sendian: little
84 cendian: big
85 Here, '$port' means to use the default XPA name service port (14285).
87 not a port environment variable.
88 Access permission for remote client machines can be stored in a file on
90 the local machine pointed to by the XPA_ACLFILE environment variable or
91 using the XPA_DEFACL environment variable. See <A HREF="./acl.html">XPA
92 Access Control for more information.
93 Remote Registration
95 If xpans is running on the remote client machine, then a local xpaset
97 command can be used with the -remote sub-command to register the local
98 XPA service in the remote name service, while at the same time giving
99 the remote machine permission to access the local service. For exam‐
100 ple, assume again that "stest" is running on the local machine and that
101 xpans is also running on the remote machine. To register access of
102 this local xpa on the remote machine, use the xpaset and the -remote
103 sub-command:
104 [sh]$ ./xpaset -p xpa -remote 'remote_machine:$port' +
106 To register the local xpa access point on the remote machine with
108 xpaget access only, execute:
109 [sh]$ ./xpaset -p xpa -remote 'remote_machine:$port' g
111 Once the remote registration command is executed, the remote client
113 machine will have an entry such as the following in its own xpans name
114 service:
115 [csh]$ xpaget xpans
117 XPA xpa gs 88877766:2839 eric
118 The xpa access point can now be utilized on the remote machine without
120 further setup:
121 [csh]$ xpaget xpa
123 class: XPA
124 name: xpa
125 method: 838e2f68:2839
126 sendian: little
127 cendian: big
128 To unregister remote access from the local machine, use the same com‐
130 mand but with a '-' argument:
131 [sh]$ xpaset -p xpa -remote 'remote_machine:$port' -
133 The benefit of using remote registration is that communication with
135 remote access points can be mixed with that of other access points on
136 the remote machine. Using Access Point Names and Templates, one XPA
137 command can be used to send or receive messages to the remote and local
138 services.
139 XPANS Proxy Registration
141 The two methods described above are useful when the local and remote
143 machines are able to communicate freely to one another. This would be
144 the case on most Local Area Networks (LANs) where all machines are
145 behind the same firewall and there is no port blocking between machines
146 on the same LAN. The situation is more complicated when the XPA server
147 is behind a firewall, where outgoing connections are allowed, but
148 incoming port blocking is implemented to prevent machines outside the
149 firewall from connecting to machines inside the firewall. Such incoming
150 port blocking will prevent xpaset and xpaget from connecting to an XPA
151 server inside a firewall.
152 To allow locally fire-walled XPA services to register with remote
154 machines, we have implemented a proxy service within the xpans name
155 server. To register remote proxy service, xpaset and the -remote sub-
156 command is again used, but with an additional -proxy argument added to
157 the end of the command:
158 [sh]$ ./xpaset -p xpa -remote 'remote_machine:$port' g -proxy
160 Once a remote proxy registration command is executed, the remote
162 machine will have an entry such as the following in its own xpans name
163 service:
164 [csh]$ xpaget xpans
166 XPA xpa gs @88877766:2839 eric
167 The '@' sign in the name service entry indicates that xpans proxy pro‐
169 cessing is being used for this access point. Other than that, from the
170 user's point of view, there is no difference in how this XPA access
171 point is contacted using XPA programs (xpaset, xpaget, etc.) or
172 libraries:
173 [csh]$ xpaget xpa
175 class: XPA
176 name: xpa
177 method: 88877766:3053
178 sendian: little
179 cendian: big
180 Of course, the underlying processing of the XPA requests is very much
182 different when xpans proxy is involved. Instead of an XPA program such
183 contacting the XPA service directly, it contacts the local xpans. Act‐
184 ing as a proxy server, xpans communicates with the XPA service using
185 the command channel established at registration time. Commands (includ‐
186 ing establishing a new data channel) are sent between xpans and the XPA
187 service to set up a new message transfer, and then data is fed to/from
188 the xpa request, through xpans, from/to the XPA service. In this way,
189 it can be arranged so that connections between the fire-walled XPA ser‐
190 vice and the remote client are always initiated by the XPA service
191 itself. Thus, incoming connections that would be blocked by the fire‐
192 wall are avoided. Note that there is a performance penalty for using
193 the xpans/proxy service. Aside from extra overhead to set up proxy
194 communication, all data must be sent through the intermediate proxy
195 process.
196 The xpans proxy scheme requires that the remote client allow the local
198 XPA server machine to connect to the remote xpans/proxy server. If the
199 remote client machine also is behind a port-blocking firewall, such
200 connections will be disallowed. In this case, the only solution is to
201 open up some ports on the remote client machine to allow incoming con‐
202 nections to xpans/proxy. Two ports must be opened (for command and data
203 channel connections). By default, these two ports are 14285 and 14287.
204 The port numbers can be changed using the XPA_NSINET environment vari‐
205 able. This variable takes the form:
206 setenv XPA_NSINET machine:port1[,port2[,port3]]
208 where port1 is the main connecting port, port2 is the XPA access port,
210 and port3 is the secondary data connecting port. The second and third
211 ports are optional and default to port1+1 and port1+2, respectively.
212 It is port1 and port3 that must be left open for incoming connections.
213 For example, to change the port assignments so that xpans listens for
215 registration commands on port 12345 and data commands on port 28573:
216 setenv XPA_NSINET myhost:12345
218 Alternatively, all three ports can be assigned explicitly:
220 setenv XPA_NSINET remote:12345,3000,12346
222 In this case 12345 and 12346 should be open for incoming connections.
224 The XPA access port (which need not be open to the outside world) is
225 set to 3000.
226 Finally, note that we currently have no mechanism to cope with Internet
228 proxy servers (such as SOCKS servers). If an XPA service is running on
229 a machine that cannot connect directly to outside machines, but goes
230 through a proxy server instead, there currently is no way to register
231 that XPA service with a remote machine. We hope to implement support
232 for SOCKS proxy in a future release.
233
235 See xpa(n) for a list of XPA help pages
236version 2.1.12 January 26, 2010 xpainet(n)