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.

About this task

Configuration methods: These instructions describe how to manually modify aspera.conf. You can also add and edit these parameters that use asconfigurator commands. For more information on using asconfigurator, see User, group, and default configurations. Run the following command to retrieve a complete default aspera.conf file that includes the asconfigurator syntax for each setting:
# asuserdata -+

Procedure

  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>enabled</fips_mode>          <!-- Transfer in FIPS-140-2-certified encryption mode -->
    <strict_allowed_cipher>false</strict_allowed_cipher>    <!-- Allow transfer when client lacks GCM   --> 
    <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>                            
 <chunker_max_mem></chunker_max_mem>            <!-- Limit memory sender uses -->
 <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 -->
</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 in the GUI or Controlling bandwidth usage with virtual links from the 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.
    • true - Locks the target rate of incoming transfers.
    • false - 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.

    		 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 and 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.
    • true - Locks the minimum rate of incoming transfers.
    • false - 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.

    		 true or false false
    Incoming Bandwidth Policy Allowed The bandwidth policies that incoming transfers can use. These policies 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 allow 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 use 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 use 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 the bandwidth is shared 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. Use the fixed policy only for specific contexts, such as bandwidth testing, otherwise, avoid the use of this policy. The fixed policy requires a maximum target rate.
    • aggressiveness - The aggressiveness of transfers that are authorized by this access key in claiming available bandwidth. Value can be 0.00-1.00. For example, these values correspond to the policy option where a policy of high approximates to aggressiveness of 0.75, fair to 0.50 and low to 0.25. Aggressiveness can be used if you need to fine-tune the transfer policy.
    		 high, fair, low, fixed fair
    Incoming Bandwidth Policy Lock Lock the bandwidth policy of incoming transfer sessions.
    • true - Locks the bandwidth policy of incoming transfer sessions.
    • false - Allow users to adjust the bandwidth policy.
    		 true or false false
    Incoming Priority Allowed The highest priority that 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. This option can 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 the transfers.
    • delay-odp - A queue-scaling controller for overdrive protection.
    • delay-adv - An advanced rate controller.
    • delay-laq - A loss-adjusted queuing (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 so that the 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. See 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 must 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.

    For more information, see Increasing transfer performance by using an RTT Predictor.

    • unset - The transfer queuing is not specified, therefore, the static transfer queuing is used.
    • static- Specified transfer queuing is good for most internet connections.
    • dynamic- Specified transfer queuing is good for satellite and other radio connections.
    		 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 in the GUI or Controlling bandwidth usage with virtual links from the 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, therefore, 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.
    • true - Locks the target rate of outgoing transfers.
    • false - 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 exceeds the minimum rate cap are ignored. The default value of unlimited applies no cap to the minimum rate.

    		 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.
    • true - Locks the minimum rate of outgoing transfers to the default value.
    • false - Allow users to adjust the minimum transfer rate.
    This setting is not relevant to transfers with a fixed bandwidth policy.    		 true or false false
    Outgoing Bandwidth Policy Allowed The bandwidth policies that outgoing transfers can use. 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 allow 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 use 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 use 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 the bandwidth is shared 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. Use the fixed policy only for specific contexts, such as bandwidth testing, otherwise, avoid the use of this policy. The fixed policy requires a maximum target rate.
    • aggressiveness - The aggressiveness of transfers that are authorized by this access key in claiming available bandwidth. Value can be 0.00-1.00. For example, these values correspond to the policy option where a policy of high approximates to aggressiveness of 0.75, fair to 0.50 and low to 0.25. Aggressiveness can be used if you need to fine-tune the transfer policy.
    		 high, fair, low, fixed fair
    Outgoing Bandwidth Policy Lock Lock the bandwidth policy of outgoing transfer sessions.
    • true - Locks the bandwidth policy of outgoing transfer sessions.
    • false - 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. This option can 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 the transfers.
    • delay-odp - A queue-scaling controller for overdrive protection.
    • delay-adv - An advanced rate controller.
    • delay-laq - A loss-adjusted queuing (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 so that the 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.

    For more information, see Increasing transfer performance by using an RTT Predictor.

    • unset - The transfer queuing is not specified, therefore, the static transfer queuing is used.
    • static- Specified transfer queuing is good for most internet connections.
    • dynamic- Specified transfer queuing is good for satellite and other radio connections.
    		 unset,static, dynamic unset
    Content Protection Required true - Requires that uploaded content is 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, despite entering a passphrase, the file remains encrypted. If HTTP fallback occurs during upload, despite entering a passphrase, the files are not encrypted.
    		 true or false false
    Strong Password Required for Content Encryption

    true - Requires that the password for content encryption that is the client-side encryption at rest.

    The password must include 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. For security, you must 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 or older, unless <strict_allowed_cipher> is set to false. 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 Ascp command reference and Ascp4 command reference.

    Values:

    • any - allow transfers that use any encryption cipher or none.
    • none - require unencrypted transfers. For security, avoid using this value.
    • 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 that depends 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 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 (V.4.4.6)

    Set fips_mode to enabled or required so that ascp uses a FIPS 140-2 certified encryption module. Enabling FIPS mode might delay startup while the system verifies the FIPS module.

    The fips_mode option supports three values: enabled, disabled, and required. Use enabled or required to activate FIPS mode. The older true and false values remain supported for compatibility with earlier versions.

    When you set fips_mode to enabled or required, both systems must use compatible FIPS settings for transfers to succeed. If any of the systems use required but the other system does not use enabled or required, the transfer fails.

    If you use passphrase-protected SSH keys, they must be FIPS-compliant. This means either generating them using ssh-keygen on a FIPS-enabled system, or converting existing keys to a FIPS-compatible format by running: 
    openssl pkcs8 -topk8 -v2 aes128 -in id_rsa -out new-id_rsa
    Important: When set to enabled, all ciphers and hash algorithms that are not FIPS-compliant stops transfers.
    		 enabled, required, disabled disabled
    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 must be only 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 initiated 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. When configured the server-side, ascp process tells ascp clients to send UDP data to this port. integer in the range 1024 - 65535 33001
    Disable Packet Batching Set to true to send data packets back-to-back (no sending a batch of packets). Resulting in a 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 causes that the Aspera sender uses its default internal buffer size, which might 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 true
    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 bidirectional 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
    Limit memory sender uses

    Use of <chunker_max_mem> is necessary when you have a high transfer rate, a significantly lossy or slow network between the sender and receiver, are sending large files (in the Gigabyte range), and the sending host does not have a generous amount of RAM to spare. The <chunker_max_mem> element limits the amount of memory (defined in bytes) that the sender uses to hold on to data that has yet to be acknowledged by the receiver. This means that the sender temporarily stops reading data that is send as for as long as that limit is reached.

    		 positive integer none
    Run File Validation at File Start Validate files by using the specified method when a file transfer starts (before file transfer starts). For more information, see Inline file validation and Automated execution of Lua scripts with transfer Events. 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 and Automated execution of Lua scripts with transfer Events and Automated execution of Lua scripts with transfer Events. 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 and Automated execution of Lua scripts with transfer Events. 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 and Automated execution of Lua scripts with transfer Events. lua_script or none none
    Run File Validation when Crossing File Threshold (Validation Threshold) Validate files by using the specified method when 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 and Automated execution of Lua scripts with transfer Events.
    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, a complete file transfer might 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 exits 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 might perform different types of validations for different or for 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 happens for every file.

    The entry must 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, options are defined, this value is ignored. For more information on inline file validation, see Inline file validation and Automated execution of Lua scripts with transfer Events.    		 Base64-encoded string Blank
    File Path to Lua Action Script For LUA API validation, the path to the Lua script, or the Base64-encoded Lua script. For more information, 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:
    # asuserdata -v