| At line 12 changed one line |
| /C:/real_path_to/CrushFTP9/Java/bin/java.exe" -jar CrushFTP.jar -dmz 9000 |
| /C:/real_path_to/CrushFTP10/Java/bin/java.exe" -jar CrushFTP.jar -dmz 9000 |
| At line 17 changed one line |
| /C:/real_path_to/CrushFTP9/Java/bin/java.exe" -jar CrushFTP.jar -dmz 9000 |
| /C:/real_path_to/CrushFTP10/Java/bin/java.exe" -jar CrushFTP.jar -dmz 9000 |
| At line 21 changed one line |
| /C:/real_path_to/CrushFTP9_PC/java/bin/java.exe" -jar CrushFTP.jar -dmzi 9000 |
| /C:/real_path_to/CrushFTP10/Java/bin/java.exe" -jar CrushFTP.jar -dmzi 9000 |
| At line 79 removed one line |
| Then alter the new service\wrapper.conf file and change the "plugins/lib/CrushFTPJarProxy.jar" to be "CrushFTP.jar". |
| At line 83 changed 8 lines |
| !DMZv1 protocol methodology: |
| Opens a read and write socket. Two sockets for all queue messages between servers. Initiated from internal server to DMZ. Then it opens 50 data sockets for whenever they might be needed, they are available for quick usage not needing any additional delay to request one. This would be for things like a login, dir listings, upload, download...etc. All user protocol type interactions. We only let these sockets remain unused for a maximum of 8 seconds, then we discard them to make sure a firewall hasn't possible dropped a socket and we go to use it and don't realize its been killed by the firewall. When he socket count drops below 50, we add more. So its a continuous cycle of adding and dropping sockets and discarding sockets that are used and so on. *LOTS* of new socket activity.\\ |
|
| !DMZv2 methodology |
| This protocol was discontinued. It attempted to route DMZv1 through a SSH tunnel between servers which revealed inefficiencies and bugs in SSH tunneling.\\ |
|
| !DMZv3 methodology: |
| There are 4 sockets. Read/write tunnel sockets for system type actions, and read/write tunnel sockets for data type actions. No other sockets are created. All other activity is tunneled inside of those 4 sockets between the Internal and DMZ host. the tunnel is not a reverse tunnel, so architecturally it functions the same as the way DMZv1 does. v3 has the DMZv1 protocol running inside of it, but it doesn't discard sockets since it knows it can trust the tunnel not to timeout or discard sockets. So that part of the protocol still functions the same. DMZv3 also handles disconnections on the sockets. If any of the 4 sockets get disconnected, it re-establishes the connection and resends any part of the tunneled messages that didn't make it across. So its added automatic retry and robustness to this. The dmz_tmp folder for this tunneling is due to the fact we can't stop or slow down the entire socket in the event one of the destination sockets on t he other side can't accept the data or has timed out. We instead buffer this to disk temporarily and then consume it the first moment we can. The expectation here is that the DMZ's internal communication pipe is faster than the internal or external communications that clients are doing.\\ |
| !DMZv1 protocol methodology:\\ |
| Opens a read and write socket. Two sockets for all queue messages between servers. Initiated from internal server to DMZ. Then it opens 50 data sockets for whenever they might be needed, they are available for quick usage not needing any additional delay to request one. This would be for things like a login, dir listings, upload, download...etc. All user protocol type interactions. We only let these sockets remain unused for a maximum of 8 seconds, then we discard them to make sure a firewall hasn't possible dropped a socket and we go to use it and don't realize its been killed by the firewall. When he socket count drops below 50, we add more. So its a continuous cycle of adding and dropping sockets and discarding sockets that are used and so on. *LOTS* of new socket activity. PRIMARY AND PREFERED PROTOCOL\\ |
| \\ |
| !DMZv2 methodology:\\ |
| This protocol was discontinued. It attempted to route DMZv1 through a SSH tunnel between servers which revealed inefficiencies and bugs in SSH tunneling libraries. DISCONTINUED\\ |
| \\ |
| !DMZv3 methodology:\\ |
| There are 4 sockets. Read/write tunnel sockets for system type actions, and read/write tunnel sockets for data type actions. No other sockets are created. All other activity is tunneled inside of those 4 sockets between the Internal and DMZ host. the tunnel is not a reverse tunnel, so architecturally it functions the same as the way DMZv1 does. v3 has the DMZv1 protocol running inside of it, but it doesn't discard sockets since it knows it can trust the tunnel not to timeout or discard sockets. So that part of the protocol still functions the same. DMZv3 also handles disconnections on the sockets. If any of the 4 sockets get disconnected, it re-establishes the connection and resends any part of the tunneled messages that didn't make it across. So its added automatic retry and robustness to this. The dmz_tmp folder for this tunneling is due to the fact we can't stop or slow down the entire socket in the event one of the destination sockets on t he other side can't accept the data or has timed out. We instead buffer this to disk temporarily and then consume it the first moment we can. The expectation here is that the DMZ's internal communication pipe is faster than the internal or external communications that clients are doing. DISCONTINUED\\ |
| \\ |
| !DMZ v4 methodology:\\ |
| back to ssh tunnel with maverick, learned the hard way, tunnel in ssh is still very unsafe for high volume usage. Gave up on the attempted fixes, rolled back libraries, and tunneling in SSH is unsafe still. DISCONTINUED\\ |
| \\ |
| !DMZ v5 methodology:\\ |
| Only for CrushFTP v10 because some customers still had no stable means of DMZ due to their firewalls. Tunnels all of DMZ v1 traffic through its sockets similar to how DMZ v3 does, no timeouts on sockets. Instead of tunneling everything through one socket like v3 did, it now tunnels everything through individual sockets. It keeps a pool of sockets for reusing them so there aren’t a lot of new sockets created, and the sockets stay fairly active and busy. If any socket dies, it at most can affect one single action…but not the entire DMZ communication channel (the DMZv3 flaw). So traffic is still encapsulated/tunneled inside another socket, but this allows for validation of the socket being good or not and confirmation of traffic making it to the other side and so on. BACKUP PROTOCOL FOR CUSTOMERS WITH NETWORKING ISSUES.\\ |
