Minor version : improving performances

Improve performances during authentication

Once a client is connected and authenticated, as long as the connection stay valid, the authentication process
could be skipped since the remote partner is already authenticated.
Note however that this optimization might not be compatible with R66 proxy based partner, since the connection might be
shared among several real partners over the R66 proxy.
To disable this, specify the option -Dopenr66.authent.noreuse=1

Improve Database update number of calls

During initialization of the transfer, many updates are done, most of all are not essential (if anything goes right).
So, except if something wrong happened, updates during initialization are minimized (from 6 to 2 roughly).

Improve check of path for config, in, out, archive, work to be under base directory

In order to prevent "Chroot defect", the global configuration and the rules configuration are checked up against base directory.
They must be relative subdirectories.
Note it is still possible to mount or symbolicly link to another place, but the "virtual" directory must be a subdirectory under the base one.

Fix issue #103

Possibility to change Transfer ID to use Long GUID instead of SQL Sequence

Some users sometimes erazed their database, loosing the current sequence value for the transfer ID, giving issues when trying to contact partner which will have the very same ID for a new transfer, which is not allowed (unicity). While it is simple to fix by setting the sequence to start to a number higher than the biggest one already used, we decide to make 2 changes:

1. SQL Sequence will be created with starting value as current time (EPOCH as long), thus preventing from already used id
2. Propose another way to assign id, using a Long GUID, which should prevents this kind of issue too.
   To set this active, you have to specify -Dopenr66.transfer.guid=1 as JVM arguments.

We also add an option to ServerInitDatabase as -minimalSeq value, where value can be the value to start from when assigning new transfer ids.

Fix issue #102

Also:

• Upgrade dependencies
• Fix bad init of some Benchmarks
• Fix bad check within tests (issue #100 and issue #99) and improve passing tests under heavy loaded CICD (issue #104)
• Fix bad behavior on some functions where role has to be correct but then wrong exception occurs (create
  NoCorrectAuthentication)
• If supported, MariaDB will use native SQL Sequence (from 10.3)
• Clean up code

Some Benchmark Results Update

Waarp R66 Benchmarks

• Loop Benchmarks : 2 Waarp Servers, 1 with PostgreSQL as Container, 1 with H2 Database on the same server with 2000 files of size average of 250 KB
  • TLS efficiency: up to 149 trasfers/second
  • No TLS efficiency: up to 150 transfers/second
• Dual Waarp servers on the same host with the same PostgreSQL Database as Container and Filesystem with one Client on the same server with 4000 concurrent transferts of size average of 250 KB
  • 1 server: 85 transfers/second with 25% CPU usage
  • 2 servers: 178 transfers/second, so 100% more than 1 server in cluster, 40% more compare to 1 server only, with 45% CPU usage
  • 4 servers: 346 transfers/second, so 100% more than 2 server in cluster, 180% more compare to 1 server only, with 80% CPU usage
• Big file transfers: up to 300 MB/s (2 400 Mbps)
• Improvements: using a 2 CPU (4 vcore) and 16 GB RAM laptop with 2 instances of Waarp R66 on it using TLS
  • v3.0 ~ 30 transfers/s 100% CPU,
  • V3.2 ~60 t/s 100% CPU,
  • v3.5.2 ~71 t/s 100% CPU,
  • v3.6.0 ~ 100 t/s 90% CPU
  • v3.6.1 ~ 124 t/s 80% CPU
  • on a 4 CPU (8 vcore), 2 instances: v3.6.1 ~ 150 t/s 35% CPU

Gateway FTP Server benchmark

• 8 threads (4 core), 16 GB Memory
  • Single FTP client
  • Using Waarp FTP client (based on FTP4J): with 1KB file
    • Passive: 77 transfers/s
    • Active: 118 transfers/s
  • Same with 100 concurrent clients
    • Mixte Passive/active: 4200 transfers/s

IMPORTANT: DEB, RPM and other distribution (except JAR) are not yet official.