Correct, a 2.x server can talk to a 3.x client. Keep in mind that the server is the sender (run on demand) and the client is the receiver (run as a daemon).
Client and server compatibility is as follows: 4.x server -> 4.x client 3.x server -> 3.x client 2.x server -> 2.x client 2.x server -> 3.x client
The uftpd log doesn't show any message about loading any keys. That indicates that the client was compiled without support for encryption. You'll need to recompile the client with encryption enabled.
This error is returned if the chosen symmetric key type is not supported by the receiver in question. Can you show the uftpd logs (including startup) when this happens? My guess is that either it was not compiled with encryption support or the installation of OpenSSL does not support DES.
Glad I could help. Post back and let me know how it works out.
Ideally, the ratio would be between 1:500 and 1:1000, but you should be able to go as high as 1:2000 if need be.
UFTP has been used in environments with over 1000 clients. When dealing with a number of clients on that scale, you may want to look into using the proxy component to allow for response aggregation.
The logs indicate there was an interruption in the flow of data. At the time the timeout occurred at the client, it had not received any packets from the server in more than 1 second, while packets were arriving much more frequently before, less than 1 ms in some cases. Run wireshark or tcpdump on both sides to see where packets might be getting lost.