Xfer Protocol

X1Xfer is an Internet transport protocol designed by United Business Technologies (UBT). UBT has very high aspirations for Xfer on the order of industry wide adoption that will shape and drive the future of the Internet by allowing devices on private networks to be accessed from outside the private network or over the internet.

With the advancement of networks, today more than ever before, the need for a new protocol such as Xfer is paramount. Xfer provides connectivity solutions in common cases that previously would have required new hardware or special firewall configurations to connect into private sub-networks in homes and offices through the Internet.

UBT has been perfecting Xfer through research and development for over 10 years. The product is solid and ready for production use. Although the product you are evaluating is an application that only runs on Windows called Xfer, this Windows product shares the same name as the protocol it is built on. That protocol has been implemented and tested on Linux and other operating systems as well as Windows.

Evaluation is here: https://www.dropbox.com/s/2fw7q4531gdaq0f/Xfer%20Eval.zip?dl=0

This document online: https://brianaberle777.wordpress.com/xfer-protocol/

This document online as PDF: https://brianaberle777.files.wordpress.com/2015/07/xfer1.pdf     (8/18/2015)

Public portions of the Xfer source code: http://www.codeproject.com/Articles/37850/XMLFoundation

Xfer is synonymous to an engine. It may power all types of vehicles, but an engine needs to be put into a vehicle to see how well it performs. This graphical user interface, titled Xfer, shows the engine at work by allowing many system operations to be remotely maintained through Xfer. The vehicle in this case is an exceptional tool, but you are encouraged to keep in mind that what is under the hood has been carefully designed to drive many types of applications developed in a wide array of languages running on various operating systems that can utilize enhanced connectivity into private subnets, regardless of firewall configurations.

The Windows GUI is a wrapper for the engine. The engine exists in other implementations not included in the trial version – specifically ISAPI, and CGI. Those applications route through IIS or Apache. It has been used on many other platforms although the Evaluation is limited to Windows, Android, and Linux.

Xfer built on XMLFoundation

In August 2015 the XMLFoundation expanded to include several pieces of cross platform functionality that Xfer needs and uses. The August 2015 build of Xfer integrates the very latest of XMLFoundation. As the article respectfully published bugs in VS2015, UBT also released to the public domain an upgrade for unsupported Microsoft software. The technical details ought not be in this user’s manual, they are in sections titled Platform Expansion, VC6sp7, GProcess, VS2015, and Networked – in this article: http://www.codeproject.com/Articles/37850/XMLFoundation

The Users Interface for NetStat email pings in Xfer looks like this:


It’s a handy new feature to email network stats to anyone on the list. It’s one more feature that is new to the August 2015 version of Xfer.

Running Xfer as a Windows Service – 2015

The Xfer Service exists as XferService64.exe or XferService32.exe for 64 or 32 bit systems respectively. The EXE’s will be created when the “Install” button is pressed from this dialog:


The EXE’s will be located in the same folder as Xfer.exe and there is no need to deal with a command line shell since the service can be stopped, started, installed, uninstalled, and set to manual or automatic start all from this dialog. The buttons on the right side of the dialog apply to the Service. Everything that the service can do, the Xfer.exe application can as well if the other tabs beyond “Startup” on this dialog are configured and you run the Server portion of this application using the buttons on the left side. Alternatively you can also accomplish the same using the command line shell – which is the only option on Linux – even if you setup a System V script in /etc/init.d/xfer which is the Linux equivalent to the Windows Service.

Should you need to manipulate the Windows Service from the command line, you may use the following commands:

Install                 remove     start     stop     auto     manual   run

Like this: C:> XferService64 start

All the commands are self-explanatory except perhaps “run” which will run the server from the CMD shell, and will NOT use the Windows Service Manager.

On Linux,

create this new file /etc/init.d/xfer [change ‘your-path‘ to where you have Xfer and XferConfig.xbin ]

# chkconfig: 2345 20 80
# description: Xfer Protocol
# Source function library.
. /etc/init.d/functions

case “$1” in
echo “Xfer StartUP”
/home/your-path/Xfer /home/your-path/XferConfig.xbin &
echo “Xfer ShutDown”
killproc Xfer
echo “Usage: $0 {start|stop|restart}”
exit 1
exit 0

Then enable the script

$ chkconfig –add xfer

$ chkconfig –level 2345 xfer on

Then check that the script is indeed enabled – you should see “on” for the levels you selected.

$ chkconfig –list | grep xfer

(make sure it runs in the shell before you run the System V script)

$ ./XferShell (or c:\Your\path\>XferShell)

You will see the output below if it bound to both ports:

X3If you see “Cannot use port[80] (in use ??)”  And you do Not see “Listening on port[80]”

Then: You must resolve the problem.

You must be sure that no other process like IIS or Apache has already locked port 80. This example uses 80 because this is a fully functional HTTP server. It will serve data that it proxies from another machine in the form of an HTTP response to the HTTP GET it sent to us. We can also serve disk files if we choose, and become a regular web server like IIS or Apache. By using the HTTP protocol, the Xfer protocol maintains connectivity into networking environments such as those that use HTTP Authentication or from devices on networks that only allow web browsing.

Notes: In CentOS you can bind to port 10777 as any user but only root can bind to 80.

Notes: In several linux distributions the ports are not released immediately after the process using them has ended. The port may report that it is in use for up to a minute or two after the last process that used the port has ended. Simply, exit the shell wait a minute then restart it.

ALSO know: After you have bound to the ports 10777 and 80

You also must have ports 80 and 10777 open in the firewall.

Some configurations may require “port forwarding” to be configured in your hardware firewall to open ports 10777 and 80.   In Fedora linux be sure enable WWW on 80 and add this to the “Other Ports” in your software firewall configuration like this:


On Windows, if you should need to do manually what the buttons on the right side of the Startup tab do, then you can manually configure the service like this:

Open a cmd prompt as administrator. Start/accessories then right click on “Command Prompt” and choose Run as Administrator.

At the prompt type Xfer install like this: (do not add the – before install)


Before you try out the windows service, you need to use the Windows GUI to create an XferConfig.xbin that contains the settings used by the service. The windows service Xfer.exe must exist in the same folder as XferConfig.xbin AND XferStartupLicense.xbin. You should COPY the XferConfig.xbin created by the Windows GUI into the same folder as the Windows Service. To install the service you must use an ADMINISTRATOR cmd prompt which you obtain by:

  1. Start/All Programs/Accessories/Command Prompt – RIGHT CLICK and select “Run as Administrator”
  2. Change to the folder containing the windows Xfer.exe service and type “Xfer install”
  3. Change the path in the following command then paste it in the Command Prompt:

netsh advfirewall firewall add rule name=”Xfer” dir=in action=allow program=”C:\Users\The one\Desktop\Xfer Pro\Windows Service\Xfer.exe” enable=yes

  1. Control Panel/Administrative Tools/Services – At the bottom of the list is “Xfer” RIGHT click it and select “Properties”
  2. Change startup type to Automatic, and Start the service.


This concludes the setup instructions for enabling the switchboard server in a Windows service, (should you want to do it manually).

Old School

Xfer is in a class of its own – or more accurately, it’s the first one to show up to this class. There is still no other product comparable to Xfer. What sets Xfer apart from other Internet protocols is the new concept of a “Connection Path” that is used to connect one machine to another. The connection path builds an “address” to some networked computer or device. Unlike an IP Address, an Xfer address (aka the ‘connection path’) contains more delivery information.

When you first start Xfer you will see this:


The first thing we’ll need to do is enable the Xfer protocol. You can either press the “Configure” button toward the lower right of the screen OR from the main menu select “Server Setup”.

X8Then you see this dialog:


After you enable one or more services, either press “Start” for the server inside the Graphical Xfer.exe application OR press “Start” for the Service. When the Xfer Server is running one of the two red lights will go green like this:


If you start the Server from inside the Xfer application as the above image shows, Xfer must be running as an Administrator. You may press “Elevate” which will restart the Xfer application as Administrator, then press “Start”. In the 2015 Evaluation you must save any pending config changes from the other tab pages prior to pressing “Elevate”.

Close the “Server Setup” Dialog and you’ll be back to the main Xfer window.

Use for the connect path.

In the evaluation version, username must be [superuser] and password must be [777]

Supply the three pieces of information then press enter, or press the “Go” button in the upper left..

If you see the file folders then you have accessed your own machine (aka through Xfer.


Most everywhere in the Xfer application, the left mouse click brings up a menu of options. You might skip ahead and check out the other tab pages to get the understanding of the ability of this Graphical Xfer application – but the key concept is to understand the ability of the Xfer protocol so the first item we’ll study is the Connection Path.

The Connection Path

The simplest connection path is a single computer like ( or a single computer by name (MY_LAPTOP) or even your own computer ( If you have direct network access then you supply the IP address that you want to connect to.

Within your home network, or within your office network, machines can often be reached directly so in those cases the connection path will be used in its simplest form.

A common network arrangement exposes one machine to the internet, allowing the machines on the internal network to get out to the Internet, but traffic from the Internet cannot connect into the internal machines. In some offices it looks like this:

XcIn many other offices and often in home networks it looks like this. Note that some modems have a switch built into them so what is depicted as 2 hardware devices may only be 1.

XdIn both cases the firewall is assigned two IP addresses, one on the internet, and one on the private network maybe (192.168.1.??? or 10.10.???.???). In both cases, the firewall prevents traffic from the internet from connecting into the private network.

If you want to run a public service on an internal computer, you need configure your firewall to allow such a thing, this is called “Port Forwarding”. Port Forwarding configures the firewall to service internet connections on a certain port from a machine on the internal network.

Many office managers cannot simply make port forwarding happen for lack of resources or authority. Many home users cannot simply make port forwarding happen for lack of know how. Firewall port forwarding also does not easily lend itself to running multiple public servers on the LAN on the same port.

There are many ways to utilize Xfer. In cases where Xfer can be used in conjunction with port forwarding – you will see that Xfer makes it easy to share all internal network resources over the same port.

Consider the following diagram of 3 networks. The Internet, the LAN, and the Subnet.


Forward Routes

Suppose your company has a domain name like http://www.MyCompany.Com. You can open port 10777 and forward it to a machine that is running Xfer. Xfer then becomes the gateway for a safe passage way into your whole network. Safe means that properly used encryption will only grant access to users that you have defined. Specify your machine (like MyOfficePCAddress or 192.168.1.???), you can use that as the second item in the connect route and create a connection through the gateway to your machine. So from your laptop at home you might use this connect route:

http://www.MyCompany.Com | MyOfficePCAddress

Connection routes can be either machine names or IP addresses, they are separated by a pipe ( | ). They have no limit as to how many machines can be specified.

Every machine is connected to on a certain port, the default port is 10777, so in the example given, both machines would have been connected to on port 10777 because no other port was specified. To specify a port, prefix the machine name or IP address with the “port number @”, for example http://www.MyCompany.Com | 50@MyOfficePCAddress this will connect to http://www.MyCompany.Com on port 10777 and from there connect to MyOfficePCAddress on port 50.

If you had an internal subnet that could be reached by MyOfficePCAddress, but not by http://www.MyCompany.Com, suppose it had a machine named InternalSubnetMachine, you could reach that machine also by using a connect route like:

http://www.MyCompany.Com | MyOfficePCAddress | InternalSubnetMachine

The connect routes described so far are called ‘Forward routes’ because the connection always moves forward from one machine to the next. To use forward routes, each machine must be running Xfer, and the machine on the internet must allow Xfer connections – most often requiring special firewall configuration settings.


Switchboard Routes

Xfer provides other types of connection routing also. Any machine running Xfer may act as a switchboard that joins connections from other machines that can reach the switchboard. Most often the switchboard is run on the Internet and can be reached by any machine that allows a web browser on the Internet, but switchboards may also reside within a private network to enable VPN(Virtual Private Network) clients to act as servers or peers.

Any machine name or IP address prefixed with a tilde (~) is a switchboard connection, for example, if is running the switchboard, it may create the meeting place necessary for two companies to safely access the desired internal resources. If http://www.OtherCompany.com has an internal process that http://www.MyCompany.Com wants to integrate with, that may be a good reason for using the Xfer switchboard server. Another reason may be to overcome any of the hindrances that Port Forwarding might have.

Obviously http://www.OtherCompany.com must allow the connections into their network. Xfer does not break into networks, even if Xfer does allow you to share internal resources that are traditionally regarded as protected by firewalls. This is how it’s done: At http://www.OtherCompany.com they configure a machine on the LAN running Xfer to accept remote connections through


This accepts a connection named SAPIntegration. A machine inside http://www.MyCompany.Com would then use this connection route: | ~ SAPIntegration

to connect to the machine on the private LAN inside the other company.

The flexibility becomes obvious when these two types of connections are used together. Suppose that InternalSubnetMachine cannot route to the internet because it runs the accounting system so it has been configured very securely. It can however be reached by MyOfficePCAddress for inputting invoices, and MyOfficePCAddress can reach the internet. If MyOfficePCAddress is configured to listen for an external connection named PeopleSoft at, then a machine at http://www.OtherCompany.com might connect like this:|~ PeopleSoft | InternalSubnetMachine to reach that machine. There is no limit to the depth of the connection route, even when passing through a switchboard.

Inversely – you may need to make a forward route to reach if it is not on your subnet.

InternalSubnetDevice||~ PeopleSoft | InternalSubnetMachine

Also note that you are allowed to use multiple switchboards in the same connection path – that won’t be needed often – but when it is needed Xfer will do it.

HTTP Tunneled Routes

There is still another aspect to the connection route, tunneling through HTTP. Suppose http://www.MyCompany.Com was running Apache or IIS and would only allow connections through that web server, or suppose you only have the ability to configure the web server but not the ability to setup port forwarding in your firewall. Xfer comes with very tight web server integration and can use the web server to accept the connection that gets routed down into the network. This requires configuring your web server to run the Xfer ISAPI component, and use a special prefix (http://) before any machine in a connect route that you wish to tunnel through HTTP.

http://www.MyCompany.Com |MyOfficePCAddress| InternalSubnetMachine

This will pass through your web server to route down into the private network, and there are no limitations in the ordering of a connection route, or the types of connection routes used together. You can meet at a switchboard and tunnel through a web server and cross multiple subnets all in a single connection route in any order. All machines prefixed with http:// default to port 80 rather than 10777, but that can be changed with the same notation:

88@http://www.MyCompany.Com will connect at port 88 rather than 80.


HTTP Proxied Routes

One more aspect you should be aware of: Xfer fully supports HTTP Proxies. Both the machine making an external ‘listen” and the machine making an external connection at a switchboard server may pass through an HTTP proxy to get there if that is necessary on your network. To enable the HTTP proxy you do not need to make any changes to your connection path, all you need to do is set the HTTP Proxy settings in the protocol configuration that you can find under the menu. If you need HTTP Authentication to pass through your proxy, Xfer supports that too.

Xfer will get through when nothing else can.

Xfer contains help throughout the application. The remainder of this document is a collection of screenshots where each image is followed by the help that is also inside the Xfer application accessed through theXh icon.


Files Page:

General Navigation tips:

  1. Look for right click menus. For example on the main file page right click in the upper window displays a list of commands that apply to the selected folder or file. Those commands are all valid when the Xfer endpoint is Windows or Unix. Notice that the right click menu changes over the list on the bottom of the files page.
  2. Notice the red X that appears during a pending connectionXj, if you press the X button it will cancel the pending connection.

Application notes:

There is no install program and there is no uninstall program. Xfer.exe creates XShell.dll to accomplish shell integrated file drag and drop over an Xfer connection. The first time Xfer runs it creates the XShell.dll and registers it with Windows. The windows explorer shell must be restarted for the drag and drop feature to work – and file transfer may be accomplished through the menu without drag and drop if it’s an inconvenient time to reboot or restart your shell after running Xfer for the first time.

Xfer also creates one other file, XferConfig.xbin, this is a configuration settings file so it is very easy to move an Xfer installation from one machine to another because it does not install any other files or store any settings in the registry.

XkServices Page:

The Services page displays Windows services.

The Xfer GUI allows you to view running services, Start/Stop them, and modify them much like the Windows Service Control Manager.

XlThe processes page displays all the running processes on the host operating system.

In windows, it supports 95/98/ME as well as XP/Vista/7, When Xfer is running with Administrator process elevation in Vista the process list returns additional process detail, but regardless the process information is sufficient for the GUI features such as Kill by process ID to be enabled.

The Xfer GUI works identical for UNIX based systems also. This provides a simple consistent user interface for remote administration regardless of host operating system.

The process page supports the “Run” command that is no less powerful than a DOS prompt or a UNIX shell window. When executing shell commands such as ( ps ls grep find ) in UNIX or ( net dir ipconfig ) in Windows, simply check the “Pipe results” option. You may also use the “Run” command to launch processes that do not use the shell such as notepad or vi – but be aware that they will run on the remote system.

XmThis is the registry page, it works like regedit.

XnThe network tab page allows you to browse the network from the last point in your connect path. Pressing Refresh will display a list of 3 possible network resources to browse, normally they are:

  1. Microsoft Windows Network
  2. Microsoft Terminal Services
  3. Web Client network

Expand (#1 Microsoft Windows Network) and you will see a list of workgroups like WORKGROUP

Expand the workgroup and you will see a list of network machines that might look something like this – depending on your network:




Expanding on the machine will list the network shares, perhaps a list like this


Finally when you double click the share the files browser page will be opened to that network share.

XoScripting allows you to perform groups of commands in a single operation that may contain variable arguments supplied at the time of script execution.

Building a script is very simple because every command is automatically recorded by the Xfer Script Designer. Every command that can be done through mouse clicks in the graphical interface can also be done through scripting. Even opening and closing TCP application bridges can be done through scripting.

The scripting page also serves as an audit log for all the actions that have been invoked by the Xfer user interface. The list at the top of the page contains a history of every command that has been invoked since the application was started. Right click in that list to save the command history, or clear it.

Once the basic elements of the script have been recorded, they will appear in the top list as a history of all command activity. Select one or more of the commands and drag them to the bottom list where the script built. Once the commands are in the bottom list you can reorder them as necessary by drag and drop.

Double click any item in the script to set or view the details. Any element of the details can then be replaced with a variable. You may replace part of a value or you may replace the entire value with a variable.

A common variable might be a file name. Suppose a script will be run every day to move a file, rename a file, and delete a file – and one or more of the filenames will change every day. In that case, double click the individual item and replace a specific file name with a script variable.

Another common variable may be the user name and or password. In this case you will want a single variable to be repeated in each script command so you can select every item in the bottom list (or the ones you wish to edit) and press the “Detail” button, then any change you make will affect every item you had selected.

On the “Script Edit” dialog that is opened by double clicking an item or pressing the “Detail” button press “help” to get the proper syntax for entering a variable.


TCP Application Bridges through Xfer:

An Xfer bridge gives legacy TCP Applications a whole new dimension of usage possibilities. Using a TCP application bridge is very simple. The basic concept is that Xfer manages the transport, and allows preexisting applications to inherit the security, benefits, and connection flexibility of Xfer. Any type of TCP application is compatible with an Xfer Bridge including Client/Server and Peer to Peer applications. All TCP protocol formats are supported both transactional such as HTTP and SMTP, and conversational such as Telnet or VNC.

When using an Xfer Bridge, you reconfigure the client or initiating piece of your application to connect the Xfer Bridge as if it was the final destination or the server portion of your application. The server side of your application needs not be aware that Xfer is involved with the transport at all, and it requires no changes to configuration.

To setup a bridge, you must enter a value for all 4 items in the “Required” section. Once the required fields are supplied, press “Add” to store the bridge definition. Select any bridge definition in the list and press “Start” to enable it. In the vast majority of cases, this is everything required to setup an efficient and functional Xfer Bridge.

  1. Description: Any name that will identify this bridge for you, like “My SMTP Server” or “Real VNC on my office machine”. The name can be any value and it is use for no purpose other than for you to identify the bridge.
  1. Entry Port on this machine: Normally you should use the same port that the actual server is running on. For example, use 23 for telnet, 25 for SMTP, or 5900 for VNC. This is the port that your preexisting client application will connect to, however it is not necessarily the port of the actual TCP server application. It is the bridge entry port that your client application will think is the actual server.
  1. Exit To: (IP / Name) If the last machine in the connection route is the machine that hosts your TCP server application then this value must be or the name/IP that resolves to the local computer. When the client data has been routed to the end of the Xfer connect route it will make a final connection to this destination. You may also enter another machine name or IP address that can be resolved by the last machine in the connection route – in that case – that machine does not need to be running Xfer. Also be aware that all data was encrypted while traveling through Xfer but this last connection is made in the clear most often in a trusted private network.
  1. Exit To Port: This is the port at the “Exit To (IP/ Name)” machine that the TCP server application is running on.

Usage notes: Once the bridge has been started, your TCP client application will connect to the client side of the bridge, most often at

Note that your TCP server application will not be aware that the client is not actually located on the machine at the end of the connect route. This is especially handy because many TCP server applications filter access by IP address and would not grant you permission to log in from the actual location of the TCP client at the remote side of the Xfer Bridge, or they would require special configuration changes at the server before they allowed it. Telnet is often configured to only allow a root logon from localhost connections. When the Xfer Bridge runs all the way to the desired location, then you can logon as root from anywhere and your Telnet server will happily allow the connections because it thinks that they came from localhost. This is not actually a breach of security, because the purpose for such a restriction is that the root password is never sent over the network. Xfer uses strong encryption, so in fact the root password was never sent over the network, only a ciphered version of it. Therefore the intent of the security restriction is still honored even if the actual rule is broken.

This is all the required information you must supply to setup an Xfer Bridge. That assumes that your bridge is using the current Connect Route, User, and Password from the 3 edit fields across the top of the Xfer application, and the current protocol setting from the main menu. You may want to concurrently run multiple bridges to various locations, if so you must supply the connection information under the “Override Current Values” section. This describes the optional values that be applied to an Xfer Bridge:

Connect Route: This is a standard Xfer Connection route. Often, the last machine (or the only machine) in the connection route runs the TCP Server application. The connection route may also end at a machine that can connect to the server application but is not actually running it. For example, if you run a TCP application from your office computer that connects to a server on the office network, there is no need to route Xfer all the way to actual server. The next entry describes how the remote end of the bridge can connect local, if the Xfer route goes all the way to the machine running the TCP Server, or it can make a network connection to reach the TCP Server application.

User: This is the Xfer user name that last machine in the connect route must have pre configured to allow TCP application bridge access. This is NOT the user of the actual TCP server application. For example, SMTP will require a user name that has no relation to this user, and VNC will still require a logon that is completely independent of this one.

Password: This is the password for the aforementioned user. NOT the password for the TCP server application. Enter the same password in both edit fields to be sure that you typed it correctly.

Advanced Bridge Settings

There are many ways that TCP protocols can work. The advanced settings of the Xfer bridge allows you to tune performance and gives you enough control that Xfer will be able to get the job done for you, and allows custom applications for the protocol that may have non standard needs.

Xfer is as efficient as possible, and in many cases it is actually more efficient to route your TCP data through Xfer because Xfer uses compression, and an algorithm to efficiently join small packets that reduces TCP overhead and even more importantly, reduces internet latencies that are guaranteed to double as the number of TCP packets double. You should be aware that when routing through a Switchboard server an HTTP header will prefix each packet, but the header is as small as possible and the HTTP header is only added when necessary. The HTTP header is not added for forward connect routes, unless it must pass through IIS or Apache in the ISAPI or CGI module.

Xfer uses the concept of a “token” that travels between one end of the bridge and the other. The token carries a request from the client (or peer) to the server or (or other peer), then gets the data from that side of the bridge to return back to the other.

The “TCP Application Reply Wait” is the longest time that the token will wait for data at the server side of the bridge, but if data hits the port any time before that, Xfer will immediately return it to the client side of the bridge. There are 1 Million Microseconds in a second and Xfer allows you to fine tune the transport so that every aspect of the bridge behavior is customizable.

If the “TCP Application Reply Wait” expires, then an empty token will return. Most often that translates to wasted network bandwidth so the default can be set higher or lower depending on your specific needs that may used essentially integrate a “ping” or keep alive into the protocol if you need to act on broken connections. However, broken connections will be rare when passing Xfer through a Switchboard because it is connectionless. Unlike TCP connections that will be broken if a router reboots, the Xfer connections are not broken only delayed while they are re-established and re-cached. A protocol like VNC demands a constant connection, and it will error if the connection breaks, so VNC gets it’s constant connection but only to the bridge entry point most often at from there VNC is unaware of the transport details and connections to local host are not commonly broken.

Xfer also uses a secondary token within the same session. However, the secondary tokens jop is to keep the client side transmitting while the server side is waiting in the “TCP Application Reply Wait”. This means that packets may physically arrive out of order but Xfer re-sequences them and feeds them to the TCP applications in the order than they were sent, not in the order that they arrived. The protocol may be adjusted to completely eliminate the secondary token, and therefore the packet re-sequencing. However, the secondary token adds little overhead because it only moves through the Bridge when there is data for it to carry. The overhead of the secondary token is that after it delivers the data it must return without data because that’s the duty of the primary token. The return of the secondary token is merely for HTTP conformance, the return may also be disabled, but then it would confuse HTTP proxy servers, Web Servers, and many ISP’s that assume HTTP proper. However there are cases that the secondary token return may be safely disabled.

The “Routing Instructions” may be used if you have a custom Xfer engine in your connection path.   You should normally leave it empty. There are standard routing instructions built into Xfer for authentication of switchboard connections, and they may also be used for custom processing. The routing instructions are not ciphered by the Xfer protocol. They may be ciphered by a custom process that puts them there but by default they are sent in the clear and they are attached to only the first packet in a transaction.

Select “Use HTTP Proxy” if you need to. Then supply your HTTP Proxy settings, the same setting that you must use for your browser to reach the internet. You must supply the Server and port, you may also supply a Basic HTTP Authentication string in the form of User:Password

You may also optionally supply “Remote EXE” and “Local EXE”. If you supply “Remote EXE”, then Xfer will issue a request to the remote system to execute the specified file prior to opening the bridge. Include the full path to the remote executable as it exists on the remote machine, and specify any startup arguments like this:

C:\Program Files\RealVNC\VNC4\winvnc4.exe         args: -noconsole

Likewise with the Local EXE, that will run the client application on your local machine when the bridge is started.

XqConfigure a replication location if you commonly need to copy a file to multiple machines. You can configure a single virtual location that represents any number of physical locations. It supports Windows shell integrated drag and drop that allows you to select any file(s) from Explorer and drop them onto the virtual location which is then the equivalent of copying to all of the physical locations you defined in that ‘drop target’.

Click ‘New’, enter any description, then press ‘Add’ for each location.

While this version of the Xfer Graphical User Interface only supports the single action of putting a file through a virtual location, it stands as a place holder for any command that may be applied to a virtual location. The concept of abstracting one or more connection routes through a named object has many usage applications.


Xfer has the built in ability to invoke custom software written in many languages.

Xfer manages the network transport then uses a built in “call interface” implemented in a “language driver” with existing implementations for languages such as Java, Perl, Python, and Visual Basic directly, plus others that can create DLL’s. This allows all languages, and preexisting systems built with them, to easily incorporate Xfer as a remote procedure call solution.

What ODBC did for databases, UBT did for development languages. UBT developed a common way to invoke methods, assign variables, create objects and make other atomic operations that all languages support. The integration aspect of this functionality is priceless on any project.

Xfer is a very useful and functional protocol, more so than RPC, even if it did not have built in integration support. RPC didn’t make any special provisions for RMI that followed many years later, Xfer is making provisions for the future, and has designed a mechanism that operates with all types of scripted and compiled languages each with special strengths that makes each one more appropriate for certain applications. Xfer is working to serve them all, and simplify integration, even with future languages.

XsXfer uses a 128 bit block cipher called TwoFish. TwoFish is one of the AES (Advanced Encryption Standard) finalists and meets the requirements of NIST (National Institute of Standards and Technology) for protection of U.S. Government information. It is certified for all federal and private use of even the most sensitive information. It has been extensively cryptanalyzed, it is fast and efficient. For these reasons, this version of Xfer does not allow any other cipher algorithms to be used. You can however, disable the cipher if the remote side of your connection will allow a non ciphered connection.

The cipher is initialized with a 256 bit SHA-2 hash. SHA (Secure Hash Algorithm) was designed by the NSA (National Security Agency) and has also been extensively cryptanalyzed. SHA-2 is the strongest variant of the SHA Hash, the successor to SHA-1, which was the successor to MD5. Again, this version of Xfer does not allow any other algorithm to be used – the decision has been made for you.

FYI: United Business Technologies has been a supplier of encryption technologies since 1996 when it released “Security Power Tools” that was built on DES (Data Encryption Standard). Prior to the year 2000, strong encryption was not allowed outside the United States, so UBT fell under the authority of the U.S. Department of Defense Trade Controls and stopped selling the product due to the liability of unenforceable international trade controls.

The compression uses BZip, a tried and tested compression algorithm that is about twice as fast at compression and six times faster at decompression compared to more popular algorithms. In this version of Xfer, you can only use this compression algorithm or you can disable compression altogether. If you are transferring large amounts of pre-compressed data, it may wise to disable it for your application.

The Xfer Protocol has been designed to allow other algorithms and has reserved protocol flags to identify alternate algorithms, but at this time no others are supported because the defaults are the best available solutions for almost every situation.

In the spirit of reserving options for the future, Xfer allows you to supply “Routing Instructions”. Routing instructions are prefixed to the leading packet of each transaction. Any point in the connection path may make special actions based on the routing instructions – it may also modify them prior to forwarding data to the next point in the connection route. You should leave the routing instructions empty, unless you wish to study the protocol with a network analyzer, to see how a user defined routing instruction is handled.

“The Xfer Engine” is a command processor that converts simple commands into Xfer packets. Protocols like HTTP are so simple that any language like Perl, or Visual Basic can easily align the data in the proper format. Because properly preparing Xfer packets would be a massive development effort in Visual Basic or Perl, a simple interface allows any language to use the full power of Xfer in minutes by sending simple commands over a socket connection to an Xfer engine – this is called the “Out of process” engine. It is compatible with all languages that can read and write to a socket.

The commands may also be prepared “In Process”, by linking a special library that may be static or dynamic. “In process” would normally be the preferred method and it is compatible with any language that can use a DLL in Windows or SO in Unix.


Every copy of Xfer has a unique license file and password embedded into it. By default the embedded password is used to cipher the configuration information that is stored on your machine in XferConfig.xbin. XferConfig.xbin may contain passwords that you use to access remote machines and it always stores passwords used to access your own machine.

The unique password embedded into every copy of Xfer cannot be viewed anywhere within the application, and it cannot be used to access any resource on your machine – the purpose of it is to cipher your configuration settings in XferConfig.xbin

UBT keeps no records of passwords that are generated for each copy of Xfer. UBT never will keep records of passwords. UBT has a high regard for privacy and to ensure that nobody at UBT could ever compromise the security of a valued customer there is no way to extract or store the 512 bit password that is generated during the software compilation process – effectively 256 bit after it is hashed and used to seed the cipher. Because you should not be expected to trust that this is the honest truth, you may supply your own password that is used to cipher the configuration settings in XferConfig.xbin

If you choose to supply your own password, you will be required to enter it every time Xfer starts because it will not be stored anywhere on your machine. For your protection, the dialog that prompts you for your custom password has your registration name on it to help prevent you from unknowingly entering your password into a look-a-like application designed to capture your password. There is a certain liability that you must assume every time you type a password in a world with keystroke loggers, rubberneckers, and security cameras. UBT has gone to great lengths to make sure that your security will never be violated by the negligence of UBT.


To create a user profile, press “Add” then enter a name and a password. To grant full permissions to the user check ‘SuperUser’. When ‘SuperUser’ is checked, there is no need to check any of the other permissions, even though they are not checked a ‘SuperUser’ has all of the permissions.

User permissions are grouped into two categories, all of the permissions under the “Files” category may be restricted to a certain folder specified in the “Restrict To:” field. This allows you to grant guests a location where they are free to get, put, and delete files without concern that anything outside their area may be accidentally or intentionally affected. Only grant ‘Run (execute)’ to trusted users, because if both ‘Put Files (write)’ and ‘Run files (execute)’ are granted, a user could upload harmful software and run it on your machine.

XvXfer contains a fully functional HTTP server like IIS or Apache. There are many configuration settings, and the GUI is being updated to edit more of them, until then every HTTP server configuration setting may be set through a simple text interface by pressing the “Manual Edit” button.

The following is some additional information on settings that you can set manually that applies to the HTTP server: If the “home” entry is empty or missing, then the switchboard will run and not allow any access to local content via the HTTP server.


Enable=either yes or no, if ‘no’ – every other value in this section is disregarded.

Index=The document returned when the browser asks for a folder but specified no document – like [www.MyCompany.com/MyFolder/]   Generally an HTTP server should have a file handy when the browser asks for (GET  /) the root folder.  This setting is optional but generally used on a public website. When not present all URL’s must be fully qualified – like: [www.MyCompany.com/MyFolder/Index.html]


Home=The base directory where your website resides


ContentCache=either yes or no, if ‘no’ – if yes then the first time the item is requested it is loaded from disk and all subsequent requests are serviced from memory.  Byte for Byte, if you have 50 Meg of content and this option is enabled then you need to have 50 Meg of memory available.


NonCacheTypes=A comma separated list of file extensions to not cache.  Only used when ContentCache=yes.  To conserve system memory you may want to exclude some file types from being permanently loaded into memory.


OnlyCacheTypes=A comma separated list of file extensions to cache.  Only used when ContentCache=yes.  If this entry does not exist then every type of file will be cached except for those listed in NonCacheTypes, if this entry does exist then only the specified types of files will be cached to memory.  This example would cache html, text and java script content files.


MaxCacheFileSize=an integer between 1 and 4.2 billion indicating the largest file size in bytes that should be cached.  Only used when ContentCache=yes.


EnableRange=either yes or no.  HTTP provides a way to request a ‘range’ of a file.  Designed to resume a partial download, but almost always used as a way to speed up transfers by requesting ranges of the same file over different connections then assembling the pieces.  This uses more server resources – some implementations actually cause the server to use even more bandwidth by requesting more of each segment than is actually necessary.  It may be viewed by some as ‘cutting in line’, and on a heavily hit server you may want to disable it to serve more individual users.


RangeZeroBeginOnly=either yes or no.  If yes, then when a request is made for a partial document beginning at the start of the file – the request will be fulfilled.  Any other begin point causes immediate disconnect.  This allows for working compatibility with most ‘download managers’ discussed in the EnableRange description, while providing the greatest processor distribution.


DisableCrawlersPage=will not be used for most public internet sites.  When this value is anything other than “no”, then it is a comma separated list of documents that when requested identify a ‘non-browser client’.  This is a way to catch heavy resource using applications that programmatically traverse your site usually for Indexing (like search engines) or Archival or for gathering email addresses for spam advertising.  In some specialized cases, at peak times, or when under attack any non-browser is unwanted traffic and may be refused.  By placing a few hidden, or nearly hidden hyperlinks to ‘junk’ non-existing pages that browser clients will never navigate to, you will pick out HTML parsing ‘crawler’ applications that cannot distinguish this page from any other sub-link on your site.  Any machine that requests one of these documents will have all subsequent connections refused for [CrawlerPenalty] seconds.


CrawlerPenalty=is a number of seconds between 1 and 4.2 billion.  It only applies when DisableCrawlersPage is a value other than “no”.  This is the number of seconds that the offending crawler will be refused service by this server.  60 is one minute.  3600 is one hour.  86400 is one day.  604800 is one week.


ShowIPAddressPageName=is a special page on your site that displays the IP address of the machine requesting that page.  You can set the value to anything you like, then any client who may not know his IP address, or the IP address of the gateway he is passing through may view it by accessing a page like [www.MyCompany.com/ShowIP]


HTTPHeaderServerName=The name of this server as reported in the HTTP headers.  Some legitimate web crawlers chart this data to get statistics, but others use it as a way to probe for certain weaknesses.  For example Servers that report IIS are often running other like technologies and may become candidate for deeper probing —  OR you get your IP and server type stored in a database then when a weakness in a server becomes public knowledge you may get whacked before the patch is installed or even available . (it’s a race between the software vendor and the hacker).  You could also report values like “Apache/1.3.20 (Win32)” or “Microsoft-IIS/5.0” or “Apache/1.3.23 (Unix)”  or “Microsoft-IIS/6.0” or “Apache/1.3.12 (Unix) ApacheJServ/1.0 madna/1.32 anses/1.12” or “GWS/2.0” or “Netscape-Enterprise/4.1” or “IBM_HTTP_Server/ Apache/1.3.12 (Unix)” like some other servers do.


This entry is optional.  If it does not appear then it is assumed that all website content is stored on disk in a not-encrypted form.  If this entry is present then it is assumed that every content file is stored in a 128 bit encrypted format that can be crated using the Xfer utility. When used in conjunction with the ContentCache – this feature causes no performance loss since the content data is cached after the first from-disk-decrypt.  This protects your content-integrity from internal resources that have obtained access to your disk.  This helps to protect against someone who has walk-up access to your web-server.


Port=The port that this HTTP server is running on.  Almost always this value should be 80.


PageRedirect=The location to redirect when a “404 Not found” error is usually issued.  This is primarily useful when your website gets re-arranged after a search engine has already indexed your site.  Rather than giving the users a broken link because your back page could not be found – you should redirect them to your home page or a site map.  This only applies to documents ending in .HTM or .HTML in any case.


404Log=The file where broken links are reported.


UseKeepAlives=either yes or no, if yes then upon request (hopefully from a browser) the connection will remain open after servicing the current request.  This does expose a bit of a weakness because an attacker could hold your connections open just for the purpose of using your system resources  So then next option, KeepAliveTimeOut, is important to consider when UseKeepAlives=yes

The maximum duration (in seconds) that a connection will be held at the request of a KeepAlive.  When under attack 7 is about a low as you should ever go, without defeating the purpose and forcing massive traffic from reconnections.


Polling is what configures a machine to register itself at a switchboard, there by allowing access to the polling machine from any machine that may directly or indirectly route to the switchboard and knows the password to access the resources you have made available on this machine.

A single machine may be registered on multiple switchboard servers, for other advanced operations select the “Manual Edit”.

SwitchBoard Server: The IP address or server name of the machine running the Xfer Switchboard.

This Server Name: Any connection name you choose.

Note: Supposing your switchboard server was and your “This Servers name” was BIG, then the remote machine looking to connect to this machine will use this connect path:

77.77.77 | ~BIG

The “SwitchBoard Path” is defined by the switchboard operator, you must use the value assigned by the switchboard operator. “SwitchBoard Name” is also defined by the switchboard operator, the switchboard administrator will decide what value you should use.

Connection Queue: 3 is typically a good value. This is the number of open connections you want to keep ready and waiting at the switchboard.

Srv wait: expiration time for waiting at the switchboard.

If this machine uses an HTTP proxy to browse the internet you should supply the same settings used by your browser here. If you use IE you can see your proxy settings by selecting the “Tools” menu then “Internet Options”, from the “Connections” tab page press “LAN Settings”. If you do not use a proxy server on your network leave the “Poll through HTTP Proxy” unchecked.

You may also register multiple entries for polling.

Press the “Manual Edit” button and you’ll see something like this:














This defines a single polling entry, all that the Graphical user interface currently supports.

The Xfer protocol allows you to define multiple polling entries by incrementing the number in the polling section entry. For example if the following 3 [sections] (and their entries removed for brevity) are in the kernel configuration settings then all three will be registered.










At the first break in the numerical order of the [PollExternalConnectN] scheme the server stops loading polling entries, so you must disable entries rather than deleting them to avoid disabling all following entries, as shown in [PollExternalConnect2].

To create multiple polling entries you must use the “Manual Config” on the “Advanced” tab because the “Manual Config” on the “Polling” tab only recognizes the [PollExternalConnect1]

XxThe Switchboard server is available on every node that runs Xfer. Security may be restricted by IP address for requests to receive other connections (servers we call them), and machines that wish to make connections (so called clients) in this peer to peer system.

IP filtering of connections in many cases is not an acceptable solution. Connections may also be restricted by a user name and password authentication scheme, where both parties must be known by the switchboard to have service there. Select the “Require Proxy and Switchboard Authentication” checkbox on the “Security” tab page to enforce user level access to the switchboard.

The name and path can be anything you choose.

Server Wait: This is the time (in seconds) that “Servers” wait in the queue before returning back to the polling server with an expired request if no client came to connect.

Client Wait: This is the time (in seconds) that “Clients” wait in the queue before returning back to the polling client if no servers are available.

Max Q: This is the most connections that can be queued.


Client connections may specify attributes of the connection, like if encryption and compression are to be used. The server may require it, or leave it to the discretion of the client, likewise with transaction sequencing and system Identification.

When Transaction Sequencing is enabled, this machine enforces that each client increment the transaction count included with each transaction. This machine keeps a transaction counter per client and ensures that it is incremented by 1 for each transaction. The first transaction always fails as the server assigns the random 64 bit transaction id that is used as a starting point for sequencing with each client. This prevents a theoretical type of attack where a hacker could record a valid encrypted string of packets representing a transaction and repeat it at a time that it was not intended.

“Require Remote System ID”            This forces connections to send remote system information including the Xfer serial number.

The Denial of Service Defensive is a unique feature. Xfer allows for automatic detection of abnormal connection frequencies, durations, and concurrent connections then places offenders in a temporary denial list that may be reviewed by an administrator.

“Max Per IP”, is the maximum connections allowed from any single IP address. That may translate to “maximum connections from a single corporation” as multiple internal IP’s appear with a common external IP at this server.

The remaining values can be left at 0 unless you have problems with hackers that flood your machine with connections designed to keep a real connection out. If so, setting FrequencyConnectLimit=20 and FrequencyTimeLimit=15 causes connections to be rejected by any IP (or all clients behind an IP gateway) that makes over 20 connections during the course of 15 seconds.

FrequencyTimeLimit= is a number between 0 and 4.2 billion.  0 indicates that this feature is turned off, any other value specifies a time limit value in seconds.  If the server encounters more than the limit (FrequencyConnectLimit) of connections in less than FrequencyTimeLimit number of seconds from the same place – then a heavy system resource user has been identified and the connection will be rejected.

FrequencyConnectLimit= is a number between 1 and 32.  This value is only used if FrequencyTimeLimit has a value other than 0.  This is the number of connections per your FrequencyTimeLimit that are allowed from any given remote IP address.


FrequencyViolatorRefuse=is a number of seconds between 1 and 4.2 billion.  It only applies when  FrequencyTimeLimit is not 0.  When a heavy resource user violates the limits you specify in FrequencyTimeLimit and FrequencyConnectLimit you may specify a duration measured in seconds that the violator is refused service from your

XzNormally there is no need to run a Remote Console on an Xfer server. The Console gives you the ability to manually end individual sessions and tune the thread pools by studying connection load. To access the Console on this machine, press “Console” on the “Startup” page. Enabling “Remote Console” allows the console to be reached remotely.

Remote Console runs on Port 10111.

The Thread Pools determine how many clients can be simultaneously serviced. Each thread in the pool allocates memory reserves. Setting the sizes will vary widely depending on use.

For example the HTTP server momentarily uses up to 2 threads per browser client from the “Primary” pool. If the HTTP ‘keep-alives’ are disabled (unwise) then fewer threads will be necessary because the thread usage will be so brief that many clients can use the same server thread.

The “Proxy” pool will mostly depend on the duration of the transactions that they proxy. If the proxy is pushing a protocol like VNC, the connections make likely be open for a long time therefore the proxy pool size will directly match the number of clients that can be serviced.

The “XProxy” pool is used for proxying only Xfer transactions.

The “Command” pool is a client side pool for caching Xfer commands.

Advanced Server Administration – The Console

Since an Xfer server may provide HTTP services, and Proxy Services as well as the basic protocol support, it may quickly become a critical piece in the corporate technology architecture. Xfer also supports “user plugins” that allows direct integration with Xfer. If Xfer or the HTTP service is tightly integrated with your backend ERP or accounting system, there may be cases where the advanced administration is necessary but for the vast majority, even on high volume integrated servers this will never be necessary. The Console will be especially useful while you are developing and testing custom user plugins.

The Console allows you to administer the running process with powerful control. Through the console you have direct access to individual thread state, and the ability to kill threads, or end connections. Normally you would not ever kill threads, however if your server is under a Denial Of Service attack or if your server has executed a plugin that is not working properly then the legitimate need to kill threads may exist.

Xfer uses a memory management scheme that limits adverse kill effects to user developed code, so killing a thread won’t cause any memory leaks or fatal state errors within Xfer – but it very likely may in your own code if you have a custom integration. Never rely on killing, but it can be the only option.

Most often a kill is not necessary, however it is available. ‘Stop‘ is also available and it is certainly the preferred approach if it accomplishes what you need. ‘Stop’ closes the connection. It is extremely likely that closing the connection will cause the thread to shut down normally when it detects the error.

The local console is the console for the in-process Server, the Remote Console may attach to a remote Xfer process if that process is configured to allow it. On the “Advanced” tab page in this server setup a server may be configured to allow remote console, a TCP service on port 10111.

This is a screen shot of the Realtime Threads administration:

XzaThreads Page

This shows you real time internal state on the running threads.

Tid = ThreadID Xfer assigns each thread a numeric ID.

Kind = the protocol mode (Xfer = 1) and (HTTP = 3)

Code = the operating system reported last error condition.

Out = the port and IP that a proxy across this machine is destined to, if none the connection is not using a proxy it will the thread viewer will display 0.

In = the port this connection came into this server on.

IP = address that the active connection came from

Time = time in seconds that this connection has been open

Seq = Sequence number. In HTTP using keep-alives this is the counts of HTTP requests. In Xfer connections are cached much the same where this number will reflect the number of Xfer transactions that have occurred on the connection.

Action – a brief description of the thread activity

Detail – is relative to the action. If Action is an HTTP GET, Detail is the file name. If the Action is “Switchboard Srv poll” the Detail shows you what server is making the request.

Once again, this is not a “log” of recent activity. This is a realtime view of current activity.

Another powerful option in the Console is the server configuration settings. This allows you to adjust things like an HTTP keep-alive timeout realtime in a running server. There are many configuration settings and all of them may changed, but not all changes are applied in realtime. Some require a server restart to take effect. The icon of a lightening bolt indicates that if the value is changed it will immediately be in effect. This is the Settings screen, where you can double click any setting to change the value under any section. You may also create and delete both sections and entries.

XzbThe console also provides Port control. You may suspend service on any port without stopping the server of affecting service on other ports. This has been proven to be handy for manually reattempting to provide service on a port that was locked by another application when Xfer started, but has now become available. Xfer will still start and provide service for all the ports that it can.


The console also provides a realtime view of all IP addresses that have triggered a temporary refusal of service. You can block or unblock or adjust the trigger values according to the data available in the console. The Console provides powerful control into the Xfer process. Since Xfer may be in the critical technology path for an entire bank, hospital, store, or government – having a low level console into the process is essential to knowing and controlling what is happening inside that process.

In Conclusion

Xfer is not designed to list files on a remote computer – that is just one application. Xfer is designed for systems integrations that require advanced connectivity. Xfer is designed to invoke custom software written in various languages through an abstract interface. Xfer is designed to solve the greatest need in software development. It provides a simple interface to a protocol that requires very little runtime configuration so that distributed systems can be efficiently and easily connected together in a safe and controlled manner.

Common Object Request Broker(CORBA) is a very prevalent technology within the Fortune 500 as well as in medium sized information systems. Object Management Group(OMG), the authority of the CORBA standard, has addressed the connectivity issue, and to no resolve. Various ORB vendors have created their own solutions to keep the underlying protocol functioning in modern networking environments. IONA (Orbix) has created “Wonder Wall” and Visigenic’s “Gatekeeper” to somewhat address the issue. These solutions deviate from mainline open systems with proprietary extensions that solve only the firewall problems in the connectivity crisis.

Microsoft has historically used their own approach to problem solving rather than following the industry guidelines, not unlike the CORBA extensions created by the leading ORB makers. Microsoft faces the same problems with Distributed COM(Component Object Model). See more on Distributed Object Protocols.

The ‘solutions’ that exist, are retrofit patches that do not address the long term interoperability issues and make no effort to address the issues of the internal subnets. Presented here is a ground up protocol that solves the issues of today and the issues that are becoming more common in connecting two endpoints over complex networking environments that commonly exists between businesses. Such a solution must eventually be embraced by OMG, W3C, ANSI, IETF, and even Microsoft.

To fully understand the situation, realize that software should not be designed around connectivity limitations – but it is. Distributed systems are not inherently based on a client/server model, but they often follow that design pattern because a more proper peer to peer design is not currently an option when portions of the system reside outside the network. Distributed computing is the natural result of networking computers. When concentrated processing occurs at the machine with the least communication inhibitions, technically – that is a design flaw.

The prevailing thought process in most corporate systems only allows foreign integration to the edge of the network. It’s the FTP mentality. It’s more proper than handing out VPN logins to your business partners, but less than ideal. A server on the edge of the network becomes a store and forward repository used to facilitate integration, or a web server runs an extra layer of command processing just to get the transaction where it needs to go. From one point of view, this is a brilliant solution because it works. From another point of view it added unnecessary complexity, additional failure points, more development time, and longer delays – because it was the only option. Xfer provides other options.

Setting up an Xfer Switchboard Server

Generally there is only 1 switchboard server per many other nodes that run the Xfer protocol. Generally it has an IP address on the internet, but there are reasons to use switchboard servers on private subnets.

First I will explain how to setup the switchboard using the “shell” server that runs in terminal or telnet session for unix/linux users or runs at the command prompt (cmd) in windows. The Xfer protocol exists in many binary formats. The “shell” is one. The windows service is one. An ISAPI extension is one. A CGI extension is one. Lastly – the Windows Xfer GUI is one which will be explained after the “shell” setup. All nodes that run Xfer (in any binary format) may act as a switchboard server.

Place the binary XferShell.exe in the same directory as XferConfig.xbin. Open a Terminal or cmd window to that location. XferConfig.xbin should contain this (although it will be encrypted).

[Xfer]Enable=yesEnableSwitchBoard=yesSwitchBoardName=SwitchBoardTimeout=120Port=10777OverrideProtected=yesUser:Brian=passwordAuth:Brian=*SwitchBoardName=SwitchBoardSwitchBoardPath=/Xfer/ServiceRepSession/SwitchBoardWaitForServer=130SwitchBoardWaitForClient=120SwitchBoardMaxQ=5 [HTTP]Port=80Enable=yesHome=/home/itc/HTTPServerHomeIndex=index.html [Trace]XferTrace=yesConnectTrace=yes

Now to start the server, type

$ ./XferShell (or c:\Your\path\>XferShell)

You will see the output below if it bound to both ports:

XzdRunning the Switchboard Server from the windows Xfer GUI.


Move to the “HTTP” tab and configure it like this:

XzfThen move to the “Switchboard” page and configure it like this:


Now you have a switchboard server running.

Now you have a web server(an HTTP server) that will accept request to join connections. The requests are a valid HTTP GET transaction that appears to be requesting a web page from a web server ( aka ‘polling’). The special requests wait for the “web page” which is actually ciphered data from another machine that could also reach this switchboard server.

Now you have a Switchboard server, you need machines/devices that “poll” the switchboard for your command. We can have Unix servers poll into the switchboard server. Its been tested with Solaris, AIX, and HPUX. We can have phones poll in. Its been tested with Windows Mobile (aka Windows CE), Android, tested on the Kindle File and LG Android phones. We can also have any kind of windows machine poll into the switchboard. Two examples for creating devices/machines that register themselves at a switchboard server will be given, first from the windows Xfer GUI, then you will see that you can do the same from the shell in Linux..

To configure a windows machine to make its self reachable through a switchboard server using the Xfer graphical interface:

From the menu select Server Setup


Move to the polling tab and configure it as shown below – but change “BriansLaptop” to “MyComputer” and change the ‘’Switchboard Server” to the name or ip address of your machine that is running your switchboard server (see the next picture)

This causes your computer to “poll” the switchboard, and become a registered device.

XziMake a user that will have some measure of access to your computer on the “Users” page as shown below. Just check “Super User” and leave everything else blank to give yourself all access to everything, or protect the machine from this user as shown below who only has disk access to the folder “c:\public”

XzjNow you must start the server for the polling to be active.

Close the server setup dialog. This completes the setup instructions for making a windows machine accessible through a switchboard server.

To configure a Unix machine to make its self reachable through a switchboard server do the following:

From the XferShell, you simply need to add this section to your XferConfig.xbin file:


“Server=” should be set to the machine that is running the Switchboard Server.

“Name=” is the name that this machine will be known by at the switchboard – each machine/device should have a unique name.

“Path=” and “Join=” must match the values used to configure your switchboard Server.

View the machines that are registered at the switchboard server in the windows GUI like this:

Press the little picture of the white guy and black guy.Xzk

Select the “Switchboard Routes” tab and press “add”

Enter this data


Do not be confused about this user “brian” this is a user known by the switchboard. This is NOT a user that will have access to your device/computer. Users with access to your machine you configure in the “users” page in the “Server Setup”. Press OK.

You will see this list of all the devices/machines that are available through the switchboard server at swb.itcdatapro.com

XzmNot everyone with access to the internet can see what connections are ready to be serviced at the switchboard. In this example the user “brian” has ‘*’ access at the switchboard server because of this line.


In your configuration at the switchboard server, if you have




Then (in the log file) you will see this message hit the log file when the Windows GUI displays the list of connections waiting:

01:08:50[111] Xfer user [brian] from [] was granted permission to [List Switchboard Users] Auth code [Y] for Cmd[SLS] DataFlags=10 tid:12 fd:6

Now – test a loopback connection to yourself.

You will connect through the switchboard back to your own computer that sent an HTTP GET on port 80 into the switchboard server because it is configured to “poll” the switchboard server.

Use this as the connection route in the main windows of the Xfer GUI to connect to the device called BRIANSLAPTOP:     switchboard   pipe   tilde   DEVICE     (like this)

swb.itcdatapro.com |~BRIANSLAPTOP

press “Go” and you will connect to yourself through the switchboard you will see this:


Known Bugs when running the 32bit Windows GUI on x64

On 64 bit Windows file drag and drop might not work, as it needs administrator rights for shell integration and it requires a shell restart. Workaround: Use the Get and Put commands on the right click menu.

On 64 bit Windows file transfer progress may not be displayed leaving the user no indication that the transfer started, is in progress, or has finished. Workaround:After the transfer has been started, from the right click menu select Refresh and you will see the file, then again from the right menu select Properties and notice the file size. If the file is in progress the size will be too small, keep checking the properties until you see the proper file size.

Xfer Evaluation is here: https://www.dropbox.com/s/2fw7q4531gdaq0f/Xfer%20Eval.zip?dl=0

 © 2015 United Business Technologies, Inc. All Rights Reserved.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s