Hello again :-)
We have some servers that are doing FFT (Fast File Transfer) directly from clients. It's like an FTP connection (using port 923), except:
- It can use more than one connection
- It tries to push as much data as possible
- It's tunable with timeout, packet size, delays, etc
I am using the default setting on the client, and have not touched the server. When I directly connect to the server, I am able to log in, transfer a file, and close a connect perfectly fine.
When I go through the STM, I am able to log in, start a transfer, and like 2.5 mins in, the server shows "client closed control stream" - but the client is still trying to send.
I am using "(Generic client first)" connections (the only one that works)
I know the STM is in-between the client and server, but it looks like the STM doesn't pass connection info back and forth.
I think it a simple configuration switch on the STM, but I can't find it.
I can try to find more info about FFT, but I think it's just a P2P bittorrent-like client/server (IE: instead of talk to lots of servers, only talks to one)
Solved! Go to Solution.
Yeah...but I don't trust it. Here's my setup:
- 3 VM's running Win2k3
- a) FFT 2.4 on standard port 923
- b) FFT 2.4 on non-standard port 20
- c) FFT 2.6 on standard port 923
All three VM's are running on a pretty old server, and I want to install a better, faster server with a later version of Windows. These server only need to run FFT and send the files via SMB to other servers.
I have found that I can create ONE pool with (a) and (b) together, and then create TWO VirtServ (x & y) to point to that pool. VS-x is on port 923 and VS-y is on port 20.
I would then present to production use (once I get it working) ONE ip address with either port (923 or 20). Port 20 is used when 923 is blocked by whatever reason.
Once this was working, I could then create an updated pool with new w2k8 VM's - all on the standard ports, and use the VirtServer (x & y) to get into via the different ports. All the new VM's would be interchangeable, and use shared disk space.
So - to answer the question again - kinda. I've found these VirtServ settings:
-New connection timeout is set to 0 seconds.
-Existing connection timeout is set to 0 seconds.
-Generic Client first
...tend to work. However, I think the VM's are being overrun, and they actually timeout (warning & errors on the Stingray)
However, it DOES work, and allows a full transfer of over 5 minutes worth of data. I've also slowed the transfer down to force it to last longer than 5 minutes, and that works too.
I just need it to work as well as a direct connection - which ALWAYS works. (sigh :-( )
FFT is a new protocol to us I think. I can't find any specifications online so it's hard to give any firm advice.
If it does operate like FTP, then it may use the model of a control connection (for control messages) and separate TCP connections for data transfers; the connections are created on demand. This sort of approach causes problems for firewalls, load balancers and other proxies because they need to inspect the control connection and prepare to admit and proxy the on-demand data connections. For example, we have an FTP proxy in Stingray that does exactly that, allowing us to proxy FTP traffic.
I saw one reference here (Hidden Value - June 2001 - question "I'm having problems using Reflection 7.0") that illustrates potential problems passing FFT through a firewall, and suggests that the client can fall back to "using the session port". Perhaps that is a feature of FFT, and one you can use?
If you can share the protocol spec, then we can advise further.
It's from Northrop Grumman Corporation.
This is the best I can do, because I've never heard of it either. I'll be at my desk running more test later today.
Cheers... it would be interesting to see a tcpdump of a successful download (from client direct to server) and a tcpdump of the connection when you try to proxy through Stingray. This might give some clues as to what is going on.
For example, the tcpdump might reveal that, like FTP, the FFT protocol attempts to create a secondary data channel between the client and the endpoint ("open a TCP connection to this IPort and await the file"). In the absence of a FFT proxy in Stingray, we might be able to persuade the client (or server) to connect directly to its peer rather than the intermediate Stingray.
All speculation of course... interested to see what you find
yeah, that was one of my first thoughts too - the tcpdump. but, it's a windows server and a windows client - and they are connected via switches (and I don't run the network) - so I can't stick anything in the middle to watch the traffic. I'll see what else I can come up with.
But, about those first suggestions, where are those switches in the GUI I can change to allow connection status?
You can run tcpdump (wireshark) on Windows (Wireshark · Download).
Switches in the GUI - there are two things you can do:
For the first setting, check the event log. For the second setting, you can drill down on the Activity > Recent Connections page.
Neither setting will give you a complete dump of the connection data, but they may help to diagnose what is happening.
we have two different versions of the FFT - 2.4 and 2.6. After testing the 2.6, it's working ok (albeit not up to the speed I want). The 2.4 gets this error (obfuscated):
Virtual Server FFT 2.4-20: "Read failure - Connection closed by peer"
Source Address 172.x.x.x:54156
Destination Address 155.x.x.6:20
Pool FFT 2.4
Local Port 38635
Connection State Reading from server
Bytes from client 16486608
Bytes to server 16486608
Bytes from server 0
Bytes to client 0
Connection Established 33s
Client Idle Time 0s
Server Idle Time 0s
Connection Retries 0
It never makes it pass 120MB transferred. Source: My desktop, Destination: STM, Node: FFT server.
More information from the FFT server - It starts to transfer fine, but after about 30 seconds - closes the link (my guess from the Stingray to the server, not from the client to the stingray)
05/23 08:55:19.771-INFO (18) User requesting file upload of \00_ROADRUNNER-01\CentOS-6.4-i386-bin-DVD1.iso.
05/23 08:55:19.791-INFO (18) Upload with block_size=64512 actual_num_streams=8.
05/23 08:55:19.881-INFO (18) Transfer of \00_ROADRUNNER-01\CentOS-6.4-i386-bin-DVD1.iso (3770155008 bytes) from 155.X.X.10
05/23 08:55:19.901-INFO Received TCP connection from 155.X.X.10
05/23 08:55:20.142-INFO Received TCP connection from 155.X.X.10
05/23 08:55:20.142-INFO (18 #0) Successfully impersonating user.
05/23 08:55:20.362-INFO Received TCP connection from 155.X.X.10
05/23 08:55:20.372-INFO (18 #1) Successfully impersonating user.
05/23 08:55:20.692-INFO Received TCP connection from 155.X.X.10
05/23 08:55:20.692-INFO (18 #2) Successfully impersonating user.
05/23 08:55:20.843-INFO Received TCP connection from 155.X.X.10
05/23 08:55:21.003-INFO (18 #3) Successfully impersonating user.
05/23 08:55:21.103-INFO Received TCP connection from 155.X.X.10
05/23 08:55:21.123-INFO (18 #4) Successfully impersonating user.
05/23 08:55:21.444-INFO Received TCP connection from 155.X.X.10
05/23 08:55:21.454-INFO (18 #5) Successfully impersonating user.
05/23 08:55:21.624-INFO Received TCP connection from 155.X.X.10
05/23 08:55:21.634-INFO (18 #6) Successfully impersonating user.
05/23 08:55:21.924-INFO Received TCP connection from 155.X.X.10
05/23 08:55:21.924-INFO (18 #7) Successfully impersonating user.
05/23 08:55:54.694-INFO (18 #3) Client closed control stream
05/23 08:55:54.945-INFO (18 #2) Client closed control stream
05/23 08:55:55.085-INFO (18 #1) Client closed control stream
05/23 08:55:55.105-INFO (18 #7) Client closed control stream
05/23 08:55:55.135-INFO (18 #4) Client closed control stream
Here's the log from the STM: Virtual Server FFT2.4-vs "Read failure - Connection reset by peer" C 172.x.x.x:57266 155.X.X.6:923 "FFT2.4" "155.X.X.41:923" 53853 "-" r 3680 3680 880 880 4003 10 10 0