Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
png
advanced_upload.png 25.7 kB 2 29-Dec-2020 05:25 Ben Spink
png
crushtunnel_diagram.png 80.7 kB 1 29-Dec-2020 05:25 Ben Spink
png
download_basket.png 39.9 kB 1 29-Dec-2020 05:25 Ben Spink
png
jnlp.png 25.7 kB 1 29-Dec-2020 05:25 Ben Spink
png
ports.png 50.1 kB 2 29-Dec-2020 05:25 Ben Spink
png
prefs_tunnel.png 77.9 kB 3 29-Dec-2020 05:25 Ben Spink
png
tunnel_only.png 74.7 kB 1 29-Dec-2020 05:25 Ben Spink
png
user_tunnel.png 22.0 kB 2 29-Dec-2020 05:25 Ben Spink
png
user_tunnel_client.png 268.4 kB 2 29-Dec-2020 05:25 Halmágyi Árpád

This page (revision-16) was last changed on 29-Dec-2020 05:25 by Ben Spink

This page was created on 29-Dec-2020 05:25 by Ben Spink

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 34 added 23 lines
----
The remote endpoint scenario takes this ability one step further by creating always-on CrushTunnel connections that are extending the location of where your CrushFTP server presents itself.
The scenario would be a main server located in the US, but high speed endpoint locations located in Europe, and Australia.
A wildcard certificate should be used on the main server in the USA. For example: *.crushftp.com, and then using DNS entries of:
us.crushftp.com —> USA IP 0 ms latency
eu.crushftp.com —> Europe IP 120ms latency
au.crushftp.com —> Australia IP 220ms latency
A virtual machine located in each of those zones would receive the connection, and simply tunnel it to the opposite side (which is always us.crushftp.com). The cert the browser would be
presented would always be the same *.crushftp.com, so all of those DNS names would be successfully matched and allowed.
Under normal conditions a 220ms of latency would yield about 2.4Mbit of speed per channel. This assumes default TCP tuning on both ends. Using 20 channels, this would now yield 48Mbit of
speed. Adjust the number of channels as needed and appropriate.
No data would be stored on these remote server locations, all data is simply being streamed. Users that are in Australia for instance would use the nearby server’s DNS to get much faster
speeds in file transfer since their local machine’s latency to that server would probably be under 40ms, or faster. The end points server locations would need to be located in ideal locations to
serve the customers with the lowest latency.
The CrushTunnel solution is CPU intensive, but light on disk usage. Disk would only be used for logging, nothing else. The CPU is used heavily in the HTTPS encryption, and tunnel
management. The benefits include on single location of data, one storage location, and one set of users.
Version Date Modified Size Author Changes ... Change note
16 29-Dec-2020 05:25 3.781 kB Ben Spink to previous
15 29-Dec-2020 05:25 3.78 kB Ben Spink to previous | to last
14 29-Dec-2020 05:25 3.741 kB Halmágyi Árpád to previous | to last
13 29-Dec-2020 05:25 3.701 kB Halmágyi Árpád to previous | to last
12 29-Dec-2020 05:25 1.828 kB Ben Spink to previous | to last
11 29-Dec-2020 05:25 2.206 kB Ben Spink to previous | to last
10 29-Dec-2020 05:25 2.232 kB Ben Spink to previous | to last
9 29-Dec-2020 05:25 2.146 kB Ben Spink to previous | to last
8 29-Dec-2020 05:25 2.019 kB Ben Spink to previous | to last
7 29-Dec-2020 05:25 3.306 kB Ben Spink to previous | to last
6 29-Dec-2020 05:25 3.3 kB Ben Spink to previous | to last
5 29-Dec-2020 05:25 3.239 kB Ben Spink to previous | to last
4 29-Dec-2020 05:25 2.863 kB Ben Spink to previous | to last
3 29-Dec-2020 05:25 2.824 kB Ben Spink to previous | to last
2 29-Dec-2020 05:25 2.684 kB Ben Spink to previous | to last
1 29-Dec-2020 05:25 2.686 kB Ben Spink to last
« This page (revision-16) was last changed on 29-Dec-2020 05:25 by Ben Spink
G’day (anonymous guest)
CrushFTP10 | What's New
JSPWiki