The aspera.conf file lets you configure the transfer server. To access the file, run the following on the machine where the transfer server is installed:

# /opt/aspera/bin/asuserdata -+

For detailed usage information, see the Aspera Enterprise Server Admin Guide (select your platform and transfer server version to access the document link).

This document will provide insight to where useful files are stored.  These files may help with debugging or may be needed in order to configure the system.

There are two modes in which the source and destination paths are passed to the ascp transfer engine; Regular Connection Mode and Persistent Connection Mode.  These two modes are explained in this document.  Currently Aspera Central and the Aspera Connect JavaScript API always invoke ascp in Regular Connection Mode.  Since version 2.6 of fasp Manager SDK users can specify the mode in which paths are passed to ascp.  Version 2.6 or later of ascp is required for Persistent Connection Mode.

Transfer Authorization is the process in which the Aspera Server allows or denies a user from performing a transfer.  In the normal workflow the user's identity is established by this point, either with a username and password or a key.  Aspera technologies support two types of authorization; token based authorization and external authorization.

Current Generation Transfer Clients and Servers utilize SSH for user authentication.  SSH typically uses the Operating System's accounts which could be on the local system or based on a remote directory service; such as LDAP and Active Directory).  There are two main methods for authentication in FASP.  You can use a User/Password combination or SSH Key Pairs.  Both methods with examples are provided in this document.

This document describes a problem often encountered while integrating Aspera technologies into a browser based application using the JavaScript APIs.  

This document covers all the known error codes that are thrown by Aspera SDK components.  Some errors below have debugging information that may help in getting to the root cause of the problem.  If you find a solution or have helpful information you wish to share with others please email us the error code and the solution for debugging.

A FASP transfer requires two ports; a TCP port and a UDP port; other ports can be involved as well, depending on your setup. When an ascp transfer is started, a SSH connection to ascp is established on the remote location in order to initiate the transfer session. The SSH connection is opened through a TCP port, usually the TCP port of the remote location. This port can be the default SSH port, TCP 22, or another port value if SSH is configured for a different port. By default, ascp assumes that the port will be 22, if this is not the case you can instruct it to use a specific port by means of the option -P, for example you could issue command -P 44002 which would initiate the session through TCP port 44002.

Inline File Validation is a feature that enables file content to be validated while the file is in transit as well as when the transfer is complete. Validation is performed by an external validation service and is triggered for downloads on the server side. The service may be implemented by writing a REST service that responds to a HTTP POST request that is issued by the ascp transfer binary for session and file events.

For detailed information about inline file validation, see the Aspera Enterprise Server Admin Guide (select your platform and transfer server version to access the document link).

Aspera Web interprets and handles FASP URLs on behalf of a web browser. FASP URLs follow the guidelines set forth in RFC 1738 - Uniform Resource Locators (URL) as published by IETF. The following is the general syntax of a FASP URL:

Video player