aspera.conf - Transfer Configuration

The settings in the <transfer> section of aspera.conf include: bandwidth control, transfer protocol options, content encryption requirements, encryption-at-rest, and inline validation.

Configuration methods: These instructions describe how to manually modify aspera.conf. You can also add and edit these parameters using asconfigurator commands. For more information on using asconfigurator, see User, Group and Default Configurations and run the following command to retrieve a complete default aspera.conf that includes the asconfigurator syntax for each setting:
# /opt/aspera/bin/asuserdata -+
  1. Open aspera.conf from the following location:

    /opt/aspera/etc/aspera.conf

  2. Add or locate the <transfer/> section, as in the following example: 
    <transfer>
 <in>
    <bandwidth>
       <aggregate>
          <trunk_id>Disabled</trunk_id>        <!-- Incoming VLink ID -->
       </aggregate>
       <flow>
          <target_rate>
             <cap></cap>                  <!-- Incoming Target Rate Cap -->
             <default>10000</default>     <!-- Incoming Target Rate Default -->
             <lock>false</lock>           <!-- Incoming Target Rate Lock -->
          </target_rate> 
          <min_rate>
             <cap></cap>                  <!-- Incoming Minimum Rate Cap -->
             <default>0</default>          <!-- Incoming Minimum Rate Default -->
             <lock>false</lock>           <!-- Incoming Minimum Rate Lock -->
          </min_rate>
          <policy>
             <allowed>any</allowed        <!-- Incoming Policy Allowed -->
             <default>fair</default>      <!-- Incoming Policy Default -->
             <lock>false</lock>           <!-- Incoming Policy Lock -->
          </policy>
          <priority>
             <cap></cap>                  <!-- Incoming Priority Allowed -->
             <default>normal</default>    <!-- Incoming Priority Default -->
             <lock>false</lock>           <!-- Incoming Priority Lock -->
          </priority>
          <network_rc>
             <module>delay</module>             <!-- Incoming Rate Control Module -->
             <tcp_friendly>false</tcp_friendly>    <!-- Incoming TCP Friendly Mode -->
             <predictor>unset</predictor>       <!-- Incoming Traffic RTT Predictor -->
             <target_queue>unset</target_queue> <!-- Incoming Rate Control Target Queue -->
          </network_rc>  
       </flow>
    </bandwidth>
 </in>
 <out>
    <bandwidth>
       <aggregate>
          <trunk_id>Disabled</trunk_id>   <!-- Outgoing VLink ID -->
       </aggregate>
       <flow>
          <target_rate>
             <cap>Unlimited</cap>         <!-- Outgoing Target Rate Cap -->
             <default>10000</default>     <!-- Outgoing Target Rate Default -->
             <lock>false</lock>           <!-- Outgoing Target Rate Lock -->
          </target_rate> 
          <min_rate>
             <cap>Unlimited</cap>         <!-- Outgoing Minimum Rate Cap -->
             <default>0</default>         <!-- Outgoing Minimum Rate Default -->
             <lock>false</lock>           <!-- Outgoing Minimum Rate Lock -->
          </min_rate>
          <policy>
             <allowed>any</allowed>       <!-- Outgoing Policy Allowed -->
             <default>fair</default>      <!-- Outgoing Policy Default -->
             <lock>false</lock>           <!-- Outgoing Policy Lock -->
          </policy>
          <priority>
             <cap>high</cap>              <!-- Outgoing Priority Allowed -->
             <default>normal</default>    <!-- Outgoing Priority Default -->
             <lock>false</lock>           <!-- Outgoing Priority Lock -->
          </priority>
          <network_rc>
             <module>delay</module>             <!-- Outgoing Rate Control Module -->
             <tcp_friendly>false</tcp_friendly> <!-- Outgoing TCP Friendly Mode -->
             <predictor>unset</predictor>       <!-- Outgoing Traffic RTT Predictor -->
             <target_queue>unset</target_queue> <!-- Outgoing Rate Control Target Queue -->
          </network_rc>  
       </flow>
    </bandwidth>
 </out>
<encryption>
    <allowed_cipher>any</allowed_cipher>  <!-- Encryption Allowed -->
    <fips_mode>false</fips_mode>          <!-- Transfer in FIPS-140-2-certified encryption mode -->
    <content_protection_required>false
    </content_protection_required>
                                          <!-- Content Protection Required -->
    <content_protection_secret></content_protection_secret>
                                          <!-- Content Protection Secret -->
    <content_protection_strong_pass_required>false
    </content_protection_strong_pass_required>
                                          <!-- Strong Password Required for Content Protection -->
 </encryption> 
 <protocol_options>
    <bind_ip_address></bind_ip_address>         <!–- Bind IP Address -->
    <bind_udp_port>33001</bind_udp_port>        <!-- Bind UDP Port -->
    <disable_batching>false</disable_batching>  <!-- Disable Packet Batching -->
    <batch_size>0</batch_size>                  <!-- Batch Size -->		
    <datagram_size>0</datagram_size>            <!-- Datagram Size -->
    <max_sock_buffer>0</max_sock_buffer>        <!-- Maximum Socket Buffer (bytes)-->   
    <min_sock_buffer>0</min_sock_buffer>        <!-- Minimum Socket Buffer (bytes)-->   
    <rtt_autocorrect>true</rtt_autocorrect>     <!-- RTT auto correction -->   
    <rtt_reverse_infer>true</rtt_reverse_infer> <!-- Reverse path congestion inference -->
    <chunk_size>0</chunk_size>                  <!-- Chunk Size -->                     
 </protocol_options>
 <validation_file_start>none</validation_file_start>               
                                               <!-- Validation File Start -->
 <validation_file_stop>none</validation_file_stop> 	  
                                               <!-- Validation File Stop -->
 <validation_session_start>none</validation_session_start> 
                                               <!-- Validation Session Start -->
 <validation_session_stop>none</validation_session_stop>   
                                               <!-- Validation Session Stop -->
 <validation_threshold>none</validation_threshold>         
                                               <!-- Validation Threshold -->
 <validation_uri>AS_NULL</validation_uri> 			 
                                               <!-- Validation URI -->
 <validation_threshold_kb>0</validation_threshold_kb> 	  
                                               <!-- Validation Threshold KB -->
 <validation_threads>5</validation_threads>    <!-- Validation Threads -->
 <validation_lua_script_base64></validation_lua_script_base64>
                                                <!-- Validation Lua Script Base64 -->
 <validation_lua_script_path></validation_lua_script_path>     
                                               <!-- Validation Lua Script Path -->
</transfer>
  3. Edit settings as needed.
    Transfer Settings Reference
    Field Description Values Default
    Incoming Vlink ID The ID of the vlink to apply to incoming transfers. Vlinks are a way to define aggregate transfer policies. For more information, see Controlling Bandwidth Usage with Virtual Links (GUI) or Controlling Bandwidth Usage with Virtual Links (Command Line). Vlink IDs Undefined (Disabled)
    Incoming Target Rate Cap (Kbps) The maximum target rate for incoming transfers, in kilobits per second. No transfer session can exceed this rate at any time. If the client requests an initial rate greater than the target rate cap, the transfer proceeds at the target rate cap. The default setting of unlimited applies no target rate cap. positive integer unlimited
    Incoming Target Rate Default (Kbps) The default initial rate for incoming transfers, in kilobits per second. If allowed ("Incoming Target Rate Lock" is set to false), clients can modify this rate in real time. This setting is not relevant to transfers with a fixed bandwidth policy. positive integer 10000
    Incoming Target Rate Lock Lock the target rate of incoming transfers to the default value (set to true). Set to false to allow users to adjust the transfer rate of an incoming transfer up to the "Incoming Target Rate Cap". true or false false
    Incoming Minimum Rate Cap (Kbps) The highest minimum rate that an incoming transfer can request, in kilobits per second. Client minimum rate requests that exceed the minimum rate cap are ignored. The default value of unlimited applies no cap to the minimum rate.
    Important: Aspera strongly recommends setting the minimum rate cap to zero. Transfers do not slow below the client's requested minimum rate unless the minimum rate is capped on the server. If the client-requested minimum rate exceeds network or storage capacity, this can decrease transfer performance and cause problems on the target storage.
    		 positive integer or unlimited unlimited
    Incoming Minimum Rate Default (Kbps) The default initial minimum rate for incoming transfers, in kilobits per second. If allowed ("Incoming Minimum Rate Lock" is set to false), clients can modify the minimum rate in real time, up to the "Incoming Minimum Rate Cap". This setting is not relevant to transfers with a fixed bandwidth policy. positive integer 0
    Incoming Minimum Rate Lock Lock the minimum rate of incoming transfers to the default value (set to true). Set to false to allow users to adjust the minimum transfer rate up to the "Incoming Minimum Rate Cap". This setting is not relevant to transfers with a fixed bandwidth policy.
    Important: Aspera strongly recommends setting a lock on minimum rate to prevent transfers from using minimum rates that can overwhelm network or storage capacity, decrease transfer performance, and cause problems on the target storage.
    		 true or false false
    Incoming Bandwidth Policy Allowed The bandwidth policies that incoming transfers can use. Aspera transfers can use high, fair, low, or fixed bandwidth policies to determine bandwidth allocation among transfers.
    • any - The server does not deny any transfer based on policy setting.
      Note: Setting to any allows clients to request a fixed bandwidth policy. If the client also requests a high minimum transfer rate and that is not capped by the server, the transfer rate can exceed network or storage capacity. This can decrease transfer performance and cause problems on the target storage. To avoid these problems, set the allowed policy to fair.
    • high - Transfers that use high, fair, or low bandwidth policies are allowed. Transfers that request fixed bandwidth policy are rejected.
    • fair - Transfers that use fair or low bandwidth policies are allowed. Transfers that request fixed bandwidth policy are rejected.
    • low - Only transfers that use a low bandwidth policy are allowed. All others are rejected.
    		 high, fair, low, or any any
    Incoming Bandwidth Policy Default The default bandwidth policy for incoming transfers. Clients can override the default policy if they specify a policy allowed by the server (see "Incoming Bandwidth Policy Allowed") and if "Incoming Bandwidth Policy Lock" is set to false.
    • high - Adjust the transfer rate to fully utilize the available bandwidth up to the maximum rate. When congestion occurs, the transfer rate is twice as fast as a fair-policy transfer. The high policy requires maximum (target) and minimum transfer rates.
    • fair - Adjust the transfer rate to fully utilize the available bandwidth up to the maximum rate. When congestion occurs, bandwidth is shared fairly by transferring at an even rate. The fair policy requires maximum (target) and minimum transfer rates.
    • low - Adjust the transfer rate to use the available bandwidth up to the maximum rate. Similar to fair mode, but less aggressive when sharing bandwidth with other network traffic. When congestion occurs, the transfer rate is reduced to the minimum rate until other traffic decreases.
    • fixed - Attempt to transfer at the specified target rate, regardless of network or storage capacity. This can decrease transfer performance and cause problems on the target storage. Aspera discourages using the fixed policy except in specific contexts, such as bandwidth testing. The fixed policy requires a maximum (target) rate.
    		 high, fair, low, fixed fair
    Incoming Bandwidth Policy Lock Lock the bandwidth policy of incoming transfer sessions to the default value (set to true). Set to false to allow users to adjust the bandwidth policy. true or false false
    Incoming Priority Allowed The highest priority the client can request. Use the value 0 to unset this option; 1 to allow high priority, 2 to enforce normal priority. 0, 1, or 2 1
    Incoming Priority Default The initial priority setting. Use the value 0 to unset this option, 1 to allow high priority; 2 to enforce normal priority 0, 1, or 2 2
    Incoming Priority Lock To disallow your clients change the priority, set the value to true true or false false
    Incoming Rate Control Module
    Set how the transmission rate should be managed relative to instantaneous network bandwidth availability. Aspera recommends that this option be changed only by advanced users.

    When the client does not specify a configuration, the server configuration is used. When the client specifies a value other than delay and the client is the receiver, then the client configuration overrides the server configuration.

    Values:

    • delay: The baseline rate control module used by Aspera transfers.
    • delay-odp: A queue-scaling controller for overdrive protection.
    • delay-adv: An advanced rate controller.
    • delay-laq: A loss-adjusted queueing (LAQ) rate controller.
      Note: The LAQ module is an experimental rate control module that is designed to solve issues with target rate overdrive, high concurrency (when many FASP sessions run at the same time), and shallow buffers (limited packet queuing capability of a router). When LAQ is set, then it uses the FD31 RTT predictor unless a different RTT predictor is explicitly set.

    To set a rate control module for outgoing traffic, set it from the command line (aspera.conf - Transfer Configuration).

    		 delay, delay-odp, delay-adv, or delay-laq delay
    TCP Friendly (for incoming rate control) This setting is meant for advanced users to turn TCP-friendly mode on or off (which is only applied at the local "receiver" side when the transfer policy is set to fair). It should only be used with special instructions for debugging. When enabled ("true"), incoming FASP transfers are allowed to maintain relative fair bandwidth share with a TCP flow under congestion. true or false false
    Incoming Traffic RTT Predictor The type of predictor to use to compensate for feedback delay when measuring RTT. An experimental feature that might increase transfer rate stability and throughput by predicting network congestion. When set to unset, the client-specified predictor is used and if the client does not specify a predictor, then none is used. For more information, see Increasing Transfer Performance by Using an RTT Predictor. unset, none, alphabeta, fd31, bezier, ets unset
    Incoming Rate Control Target Queue The method for calculating the target queue. Static queuing is good for most internet connections, whereas dynamic queuing is good for satellite and other radio connections. For more information, see Increasing Transfer Performance by Using an RTT Predictor. When set to unset, the client-specified transfer queuing method is used and if the client does not specify a queuing method, then static is used. unset, static, dynamic unset
    Outgoing Vlink ID The ID of the vlink to apply to outgoing transfers. Vlinks are a way to define aggregate transfer policies. For more information, see Controlling Bandwidth Usage with Virtual Links (GUI) or Controlling Bandwidth Usage with Virtual Links (Command Line). Vlink ID Undefined (Disabled)
    Outgoing Target Rate Cap (Kbps) The maximum target rate for outgoing transfers, in kilobits per second. No transfer session can exceed this rate at any time. If the client requests an initial rate greater than the target rate cap, the transfer proceeds at the target rate cap. The default setting of unlimited applies no target rate cap. positive integer unlimited
    Outgoing Target Rate Default (Kbps) The default initial rate for outgoing transfers, in kilobits per second. If allowed ("Outgoing Target Rate Lock" is set to false), clients can modify this rate in real time up to the "Outgoing Target Rate Cap". This setting is not relevant to transfers with a fixed bandwidth policy. positive integer 10000
    Outgoing Target Rate Lock Lock the target rate of outgoing transfers to the default value (set to true). Set to false to allow users to adjust the transfer rate of an outgoing transfer. true or false false
    Outgoing Minimum Rate Cap (Kbps) The highest minimum rate that an outgoing transfer can request, in kilobits per second. Client minimum rate requests that exceed the minimum rate cap are ignored. The default value of unlimited applies no cap to the minimum rate.
    Important: Aspera strongly recommends setting the minimum rate cap to zero. Transfers do not slow below the client's requested minimum rate unless the minimum rate is capped on the server. If the client-requested minimum rate exceeds network or storage capacity, this can decrease transfer performance and cause problems on the target storage.
    		 positive integer unlimited
    Outgoing Minimum Rate Default The default initial minimum rate for outgoing transfers, in kilobits per second. If allowed ("Outgoing Minimum Rate Lock" is set to false), clients can modify the minimum rate in real time up to the "Outgoing Minimum Rate Cap". This setting is not relevant to transfers with a fixed bandwidth policy. positive integer 0
    Outgoing Minimum Rate Lock Lock the minimum rate of outgoing transfers to the default value (set to true). Set to false to allow users to adjust the minimum transfer rate. This setting is not relevant to transfers with a fixed bandwidth policy.
    Important: Aspera strongly recommends setting a lock on minimum rate to prevent transfers from using minimum rates that can overwhelm network or storage capacity, decrease transfer performance, and cause problems on the target storage.
    		 true or false false
    Outgoing Bandwidth Policy Allowed The bandwidth policies that outgoing transfers can use. Aspera transfers can use high, fair, low, or fixed bandwidth policies to determine bandwidth allocation among transfers.
    • any - The server does not deny any transfer based on policy setting.
      Note: Setting to any allows clients to request a fixed bandwidth policy. If the client also requests a high minimum transfer rate and that is not capped by the server, the transfer rate can exceed network or storage capacity. This can decrease transfer performance and cause problems on the target storage. To avoid these problems, set the allowed policy to fair.
    • high - Transfers that use high, fair, or low bandwidth policies are allowed. Transfers that request fixed bandwidth policy are rejected.
    • fair - Transfers that use fair or low bandwidth policies are allowed. Transfers that request fixed bandwidth policy are rejected.
    • low - Only transfers that use a low bandwidth policy are allowed. All others are rejected.
    		 high, fair, low, or any any
    Outgoing Bandwidth Policy Default The default bandwidth policy for outgoing transfers. Clients can override the default policy if they specify a policy allowed by the server (see "Outgoing Bandwidth Policy Allowed") and if "Outgoing Bandwidth Policy Lock" is set to false.
    • high - Adjust the transfer rate to fully utilize the available bandwidth up to the maximum rate. When congestion occurs, the transfer rate is twice as fast as a fair-policy transfer. The high policy requires maximum (target) and minimum transfer rates.
    • fair - Adjust the transfer rate to fully utilize the available bandwidth up to the maximum rate. When congestion occurs, bandwidth is shared fairly by transferring at an even rate. The fair policy requires maximum (target) and minimum transfer rates.
    • low - Adjust the transfer rate to use the available bandwidth up to the maximum rate. Similar to fair mode, but less aggressive when sharing bandwidth with other network traffic. When congestion occurs, the transfer rate is reduced to the minimum rate until other traffic decreases.
    • fixed - Attempt to transfer at the specified target rate, regardless of network or storage capacity. This can decrease transfer performance and cause problems on the target storage. Aspera discourages using the fixed policy except in specific contexts, such as bandwidth testing. The fixed policy requires a maximum (target) rate.
    		 high, fair, low, fixed fair
    Outgoing Bandwidth Policy Lock Lock the bandwidth policy of outgoing transfer sessions to the default value (set to true). Set to false to allow users to adjust the bandwidth policy. true or false false
    Outgoing Priority Allowed The highest priority your client can request. Use the value 0 to unset this option; 1 to allow high priority, 2 to enforce normal priority. 0, 1, or 2 1
    Outgoing Priority Default The initial priority setting. Use the value 0 to unset this option, 1 to allow high priority; 2 to enforce normal priority. 0, 1, or 2 2
    Outgoing Priority Lock To prevent your clients from changing the priority, set the value to true. true or false false
    Outgoing Rate Control Module
    Set how the transmission rate should be managed relative to instantaneous network bandwidth availability. Aspera recommends that this option be changed only by advanced users.

    When the client does not specify a configuration, the server configuration is used. When the client specifies a value other than delay and the client is the receiver, then the client configuration overrides the server configuration.

    Values:

    • delay: The baseline rate control module used by Aspera transfers.
    • delay-odp: A queue-scaling controller for overdrive protection.
    • delay-adv: An advanced rate controller.
    • delay-laq: A loss-adjusted queueing (LAQ) rate controller.
      Note: The LAQ module is an experimental rate control module that is designed to solve issues with target rate overdrive, high concurrency (when many FASP sessions run at the same time), and shallow buffers (limited packet queuing capability of a router). When LAQ is set, then it uses the FD31 RTT predictor unless a different RTT predictor is explicitly set.
    		 delay, delay-odp, delay-adv, or delay-laq delay
    TCP Friendly (for outgoing rate control) This setting is meant for advanced users to turn TCP-friendly mode on or off (which is only applied at the local "receiver" side when the transfer policy is set to fair). It should only be used with special instructions for debugging. When enabled ("true"), outgoing FASP transfers are allowed to maintain relative fair bandwidth share with a TCP flow under congestion. true or false false
    Outgoing Traffic RTT Predictor The type of predictor to use to compensate for feedback delay when measuring RTT. An experimental feature that might increase transfer rate stability and throughput by predicting network congestion. When set to unset, the client-specified predictor is used and if the client does not specify a predictor, then none is used. For more information, see Increasing Transfer Performance by Using an RTT Predictor. unset, none, alphabeta, fd31, bezier, ets unset
    Outgoing Rate Control Target Queue The method for calculating the target queue. Static queuing is good for most internet connections, whereas dynamic queuing is good for satellite and other radio connections. For more information, see Increasing Transfer Performance by Using an RTT Predictor. When set to unset, the client-specified transfer queuing method is used and if the client does not specify a queuing method, then static is used. unset, static, dynamic unset
    Content Protection Required Set to true to require that uploaded content be encrypted by the client (enforce client-side encryption-at-rest).

    For more information, see Client-Side Encryption-at-Rest (EAR).

    Important: When a transfer falls back to HTTP or HTTPS, content protection is no longer supported. If HTTP fallback occurs while downloading, then–despite entering a passphrase–the file remains encrypted. If HTTP fallback occurs during upload, then–despite entering a passphrase–the files are not encrypted.
    		 true or false false
    Strong Password Required for Content Encryption Set to true to require that the password for content encryption (client-side encryption at rest) includes at least 6 characters, of which at least 1 is non-alphanumeric, at least 1 is a letter, and at least 1 is a digit. true or false false
    Content Protection Secret Enable server-side encryption-at-rest (EAR) by setting the passphrase. Files uploaded to the server are encrypted while stored there and are decrypted when they are downloaded. For more information, see Server-Side Encryption at Rest (EAR) or Server-Side Encryption-at-Rest (EAR). passphrase (none)
    Encryption Allowed Set the transfer encryption allowed by this computer. Aspera strongly recommends that you require transfer encryption. Aspera supports three sizes of AES cipher keys (128, 192, and 256 bits) and supports two encryption modes, cipher feedback mode (CFB) and Galois/counter mode (GCM). The GCM mode encrypts data faster and increases transfer speeds compared to the CFB mode, but the server must support and permit it.
    Note: To ensure client compatibility when requiring encryption, use a cipher with the form aes-XXX, which is supported by all clients and servers. Requiring GCM causes the server to reject transfers from clients that are running a version of Ascp 3.8.1 or older. When a client requests a shorter cipher key than is configured on the server (or in an access key that authorizes the transfer), the transfer is automatically upgraded to the server setting. For more information about how the server and client negotiate the transfer cipher, see the description of -c in the Ascp Command Reference.

    Values:

    • any - allow transfers that use any encryption cipher or none.
    • none - require unencrypted transfers (not recommended).
    • aes-128, aes-192, or aes-256 - allow transfers that use an encryption cipher key that is as long or longer than the setting. These settings use the CFB or GCM mode depending on the client version and cipher requested. Supports all client versions.
    • aes-128-cfb, aes-192-cfb, or aes-256-cfb - require that transfers use the CFB encryption mode and a cipher key that is as long or longer than the setting. Supports all client versions.
    • aes-128-gcm, aes-192-gcm, or aes-256-gcm - require that transfers use the GCM encryption mode introduced in version 3.9.0 and a cipher that is as long or longer than the setting.
    		 any, none, aes-128, aes-192, aes-256, aes-128-cfb, aes-192-cfb, aes-256-cfb, aes-128-gcm, aes-192-gcm, or aes-256-gcm any
    Do encrypted transfers in FIPS-140-2-certified encryption mode Set to true for ascp to use a FIPS 140-2-certified encryption module. When enabled, transfer start is delayed while the FIPS module is verified.

    When you run ascp in FIPS mode (that is, <fips_enabled> is set to true in aspera.conf), and you use passphrase-protected SSH keys, you must use keys generated by running ssh-keygen in a FIPS-enabled system, or convert existing keys to a FIPS-compatible format using a command such as the following:

    openssl pkcs8 -topk8 -v2 aes128 -in id_rsa -out new-id_rsa
    Important: When set to true, all ciphers and hash algorithms that are not FIPS compliant will abort transfers.
    		 true or false false
    Bind IP Address Specify an IP address for server-side ascp to bind its UDP connection. If a valid IP address is given, ascp sends and receives UDP packets only on the interface corresponding to that IP address.
    Important: The bind address should only be modified (changed to an address other than 127.0.0.1) if you, as the System Administrator, understand the security ramifications of doing so, and have undertaken precautions to secure the SOAP service.
    		valid IPv4 address None specified
    Bind UDP Port Prevent the client-side ascp process from using the specified UDP port. integer between 1 and 65535 33001
    Disable Packet Batching Set to true to send data packets back-to-back (no sending a batch of packets). This results in smoother data traffic at a cost of higher CPU usage. true or false false
    Batch Size When set to "0" (default), the system uses a pre-computed batch size. Set this to "1" for high concurrency servers (senders) in order to reduce CPU utilization in aggregate. Integer 0
    Datagram Size Sets the datagram size on the server side. If size is set with both -Z (client side) and <datagram_size> (server side), the <datagram_size> setting is used. In cases where the client-side is pre-3.3, datagram size is determined by the -Z setting, regardless of the server-side setting for <datagram_size>. In such cases, if there is no -Z setting, datagram size is based on the discovered MTU and the server logs the message "LOG Peer client doesn't support alternative datagram size". Integer 1492
    Maximum Socket Buffer (bytes) Set the upper bound of the UDP socket buffer of an ascp session below the input value. The default of 0 will cause the Aspera sender to use its default internal buffer size, which may be different for different operating systems. positive integer 0
    Minimum Socket Buffer (bytes) Set the minimum UDP socket buffer size for an ascp session. positive integer 0
    RTT auto correction Set to true to enable auto correction of the base (minimum) RTT measurement. This feature is helpful for maintaining accurate transfer rates in hypervisor-based virtual environments. true or false false
    Reverse path congestion inference Set to true to prevent the transfer speed of a session from being adversely affected by congestion in the reverse (non data-sending) transfer direction. This feature is useful for boosting speed in bi-directional transfers. true or false true
    Chunk Size For multi-session transfers with object storage, the chunk size must be equal to or greater than the object storage part size. For more information, see Multi-Session Transfers and Parallel Transfers to Amazon S3 and Amazon EC2. positive integer 0
    Run File Validation at File Start Validate files by using the specified method when starting a file transfer (before file transfer starts). For more information, see Inline File Validation . uri, lua_script, or none none
    Run File Validation at File Stop Validate files by using the specified method when file transfer is complete and file is closed. For more information, see Inline File Validation. uri, lua_script, or none none
    Run File Validation at Session Start Validate files by using the specified method when a transfer session starts. For more information, see Inline File Validation. lua_script or none none
    Run File Validation at Session Stop Validate files by using the specified method when a transfer session ends. For more information, see Inline File Validation. lua_script or none none
    Run File Validation when Crossing File Threshold (Validation Threshold) Validate files by using the specified method once the transfer session surpasses a set number of kilobytes (threshold). The threshold must be specified by editing aspera.conf. For more information, see Inline File Validation.

    Note: For threshold validation, the file transfer might complete before the file threshold validation response comes back (because ascp doesn't pause file transfers during file threshold validation); therefore, a complete file transfer could happen even with validation failure.

    		 uri, lua_script, or none none
    Validation Threshold KB Validate files once the download size exceeds the threshold value. Since threshold validation can only be triggered periodically (every second in the worst case), the file must be large enough to trigger this validation.

    The Validation Threshold option must also be specified (uri or lua) if this option is to be recognized by the system.

    If Validation Threshold is also enabled, and this value is not specified (or set to 0), the ascp session will exit with an error.    		 Positive integer 0
    Validation Threads Enable multiple validations to occur in parallel validator threads.

    If the number of validation threads is not set to 1, then multiple threads may perform different types of validations for different (or the same) files at the same time. In such a situation, the response of a validation_file_stop at the end of a file download might come before the response of a validation_threshold for the same file.

    		 Positive integer 5
    Validation URI Use the specified external URL for validation calls. When this parameter is defined, at least two validations, validation_file_start and validation_file_stop will happen for every file.

    The entry should define a URL, port, and URL handler for validation. For example, http://127.0.0.1:8080/SimpleValidator

    This value must be defined if any of the following values are set to uri:
    • validation_file_start
    • validation_file_stop
    • validation_ session_start
    • validation_session_stop
    • validation_threshold
    		 URL none
    Base64-Encoded Lua Action Script For Lua API validation, the path to the base64-encoded Lua script. This value or "File Path to Lua Action Script" must be defined if any of the following values are set to lua_script: Run at File Start, Run at File Stop, Run at Session Start, Run at Session Stop, Run when Crossing File Threshold. If both this option and File Path to Lua Action Script option are defined, this value is ignored. For more information on inline file validation, see Inline File Validation. Base64-encoded string blank
    File Path to Lua Action Script For Lua API validation, the path to the Lua script.
    This value or Base64-Encoded Lua Action Script must be defined if any of the following values are set to lua_script:
    • validation_file_start
    • validation_file_stop
    • validation_ session_start
    • validation_session_stop
    • validation_threshold

    If both this option and the Base64-Encoded Lua Action Script option are defined, this value is used. For more information on inline file validation, see Inline File Validation.

    		 Filepath blank
  4. Save and validate aspera.conf.
    Run the following command to confirm that the XML is correctly formatted and the parameter settings are valid:
    # /opt/aspera/bin/asuserdata -v