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 09-Oct-2016 18:14 Ben Spink
png
crushtunnel_diagram.png 80.7 kB 1 09-Oct-2016 18:14 Ben Spink
png
download_basket.png 39.9 kB 1 09-Oct-2016 18:14 Ben Spink
png
jnlp.png 25.7 kB 1 09-Oct-2016 18:14 Ben Spink
png
ports.png 50.1 kB 2 09-Oct-2016 18:14 Ben Spink
png
prefs_tunnel.png 77.9 kB 3 09-Oct-2016 18:14 Ben Spink
png
tunnel_only.png 74.7 kB 1 09-Oct-2016 18:14 Ben Spink
png
user_tunnel.png 22.0 kB 2 09-Oct-2016 18:14 Ben Spink
png
user_tunnel_client.png 268.4 kB 2 09-Oct-2016 18:14 Halmágyi Árpád

This page (revision-15) was last changed on 09-Oct-2016 18:14 by Ben Spink

This page was created on 09-Oct-2016 18:14 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 28 lines
\\
\\
\\
----
!!!Remote Endpoint Scenario
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.
[attachments|user_tunnel_client.png]
Version Date Modified Size Author Changes ... Change note
15 09-Oct-2016 18:14 3.78 kB Ben Spink to previous
14 09-Oct-2016 18:14 3.741 kB Halmágyi Árpád to previous | to last
13 09-Oct-2016 18:14 3.701 kB Halmágyi Árpád to previous | to last
12 09-Oct-2016 18:14 1.828 kB Ben Spink to previous | to last
11 09-Oct-2016 18:14 2.206 kB Ben Spink to previous | to last
10 09-Oct-2016 18:14 2.232 kB Ben Spink to previous | to last
9 09-Oct-2016 18:14 2.146 kB Ben Spink to previous | to last
8 09-Oct-2016 18:14 2.019 kB Ben Spink to previous | to last
7 09-Oct-2016 18:14 3.306 kB Ben Spink to previous | to last
6 09-Oct-2016 18:14 3.3 kB Ben Spink to previous | to last
5 09-Oct-2016 18:14 3.239 kB Ben Spink to previous | to last
4 09-Oct-2016 18:14 2.863 kB Ben Spink to previous | to last
3 09-Oct-2016 18:14 2.824 kB Ben Spink to previous | to last
2 09-Oct-2016 18:14 2.684 kB Ben Spink to previous | to last
1 09-Oct-2016 18:14 2.686 kB Ben Spink to last
« This page (revision-15) was last changed on 09-Oct-2016 18:14 by Ben Spink
G’day (anonymous guest)

OLD WIKI!!!#

New: CrushFTPv9#

OLD WIKI!!!#


CrushFTP8 | What's New
JSPWiki