Most network applications use TCP connections for communications between peers or between a client and server. When these connections run over the WAN, transmission delay and packet loss can slow your application to a crawl.
Accelerating these applications is easy, requiring no changes to any software and only minor configuration changes.
Simply create a WANFast acceleration tunnel from the client to the target service, or from peer to peer. This is a one-time configuration task that is typically added to system startup. Then reconfigure your application to connect to the local end of the tunnel rather than the remote machine directly. Each time your application connects to the tunnel, WANFast creates a new virtual connection between your application and the remote port, protecting and accelerating your communications over the WAN.
There are two types of tunnels that you can create. A local tunnel originates on your local machine and terminates on the remote machine. It uses the -L option. A remote tunnel originates on the remote machine and terminates on the local machine. It uses the -R option. The command:
wfst [Options] -L 9000:localhost:9001 [User@]ServerAddressOrIP
creates a local tunnel. It consists of three parts: any commands options, the tunnel specification, and the WANFast session information. The full list of command options can be found at wfst Client Command Syntax and Configuration Options. The tunnel specification consists of at least three parts separated by colons. The first part specifies the listening port on the originating end of the tunnel. The 2nd and 3rd parts specify the destination host (from the perspective of the terminating end of the tunnel) and the destination port, respectively. Thus the command above creates a tunnel that listens on port 9000 on the local machine and connects to port 9001 on the remote machine. In this case the remote machine is the terminating end of the tunnel, and it interprets the address "localhost" as itself. The WANFast session information consists of an optional user ID to specify the remote account for the connection and the IP address or host name of the target host. See Getting Started for details on account set up.
The command:
wfst -R 9000:localhost:9001 [User@]]ServerAddressOrIP
creates a remote tunnel that listens on port 9000 on the remote machine and connects to port 9001 on the local machine. In this case the local machine is the terminating end of the tunnel and it interprets the address "localhost" as itself.
The command:
wfst -L 9000:10.1.1.233:9001 [User@]ServerAddressOrIP
creates a local tunnel to the remote WANFast server at ServerAddressOrIP. The remote machine is the terminating end of the tunnel. It terminates the tunnel with a connection to port 9001 at address 10.1.1.233.
If the tunnel originator is not able to bind to the specified listening port, it will write an error message similar to
ERROR: wfst client: bind() -- 98, Address already in use
to its WANFast log file.
Tunnel Options
A local or remote tunnel specification can include two options. If specified, they will override the session defaults.
:zN where N is an integer, 2 <= N <= 16, specifies the size of the connection pool to use with the tunnel.
:bN where N is an integer specifies the maximum bandwidth in mpbs to be used by the tunnel.
So the command:
wfst -L 9000:10.1.1.233:9001:b500 [User@]ServerAddressOrIP
will create the same tunnel as above, but limit the maximum bandwidth to 500Mbps.
Server Options
The following are commonly used server options that can be added to the server's configuration file.
- tunnels = false Disable tunnels into or out of the server.
- max-bandwidth = int Set the maximum bandwidth used for a WANFast session.
- encrypt-alg = alg Specify the encryption algorithm. If different than the client-specified algorithm, the stronger algorithm is used.
The full list of server options can be found at wfstd Daemon Command Syntax and Options.
Audit
An audit record is written on both the client and server for each tunnel created between the two. This records the identity of the creator as well as the end points of the tunnel. A separate audit record is written each time a new virtual connection is created using the tunnel.