xpainet(n)

💖 NAME 💖

xpainet(n) — this is the page about XPAInet, aka XPA Communication Between Hosts. ✨ Coming at you from the SAORD Documentation set, bestie. 🫶

---

🦋 SYNOPSIS 🦋

the whole vibe in one line, no notes:

XPA uses standard inet sockets to support communication between two or
more host computers.

---

✨ DESCRIPTION ✨

okay so. When the Communication Method is set to inet (and yes, it's set to that by default 💅), XPA can talk between different computers on the Internet. iconic behavior honestly.

INET sockets use the IP address of the machine in question plus a (usually random) port number to let processes chat — either processes on the same machine or on different machines across the Internet. These are the exact same standard Internet sockets that programs like Netscape, ftp. etc. use. yes bestie, those sockets. 🔥

XPA has a host-based Access Control mechanism to stop unauthorized access of XPA access points by other computers on the Net. By default, only the machine running the XPA server can access XPA services. So if you wanna set up communication between a local XPA server machine and a remote client machine, you need 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 to pull off this remote registration are described below. let's get into it. 💅

🎀 Manual Registration 🎀

Method numero uno is the most basic one, and it does not require the remote client to have xpans running. To use it, the local server just gives a remote client machine access to one or more XPA access points using xpaset and the -acl sub-command. 🫶

For example, picture 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, this command can be issued on the local machine:

[sh]$ xpaset -p xpa -acl "remote_machine g"

and boom, that 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. You can do this 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 glow-up option 💅), the XPA_NSINET variable on the remote machine can be set to point directly at xpans on the local machine, which removes the need to override this value every single 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. don't get it twisted bestie 😭

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 by using the XPA_DEFACL environment variable. Peep the XPA Access Control page at ./acl.html 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. two birds, one slay. ✨

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 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 used on the remote machine without any 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 remote registration? 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 send or receive messages to the remote and local services. chef's kiss. 👑

💜 XPANS Proxy Registration 💜

The two methods above are great when the local and remote machines can communicate freely with each other. That's the case on most Local Area Networks (LANs), where all machines sit behind the same firewall and there's no port blocking between machines on the same LAN.

But it gets messier when the XPA server is behind a firewall — outgoing connections are allowed, but incoming port blocking is in place to stop machines outside the firewall from connecting to machines inside the firewall. That incoming port blocking will prevent xpaset and xpaget from connecting to an XPA server inside a firewall. 💀

To let locally fire-walled XPA services register with remote machines, a proxy service has been implemented within the xpans name server. To register remote proxy service, xpaset and the -remote sub-command is used again — but with an extra -proxy argument tacked onto 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 means 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 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. That way, connections between the fire-walled XPA service and the remote client can always be initiated by the XPA service itself. So incoming connections that the firewall would block are avoided. 🎀

⚠️ heads up bestie: there is a performance penalty for using the xpans/proxy service. Aside from the 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 is also behind a port-blocking firewall, such connections will be disallowed. In that 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 doesn't need to be open to the outside world) is set to 3000. ✨

Finally — and this is important — there is currently no mechanism to cope with Internet proxy servers (such as SOCKS servers). If an XPA service is running on a machine that can't 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. The hope is to implement support for SOCKS proxy in a future release. 🤞

---

🌟 SEE ALSO 🌟

• See xpa(n) for a list of XPA help pages. go read it, it's giving ✨main character energy✨

---

and that's the whole page bestie!! 💖 this was version 2.1.15, dated July 23, 2013, filed under xpainet(n) in the SAORD Documentation. slay, no cap. 🎀🦋💅