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.
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