cancel
Showing results for 
Search instead for 
Did you mean: 

bittorrent-like ftp client drops connection

SOLVED
Highlighted
Contributor

bittorrent-like ftp client drops connection

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)

16 REPLIES
Frequent Contributor

Re: bittorrent-like ftp client drops connection

Hi Derek,

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.

Best regards

Owen

Contributor

Re: bittorrent-like ftp client drops connection

Fast File Transfer

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.

Frequent Contributor

Re: bittorrent-like ftp client drops connection

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 IPSmiley Tongueort 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

Contributor

Re: bittorrent-like ftp client drops connection

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?

Contributor

Re: bittorrent-like ftp client drops connection

Is there anything in the Stingray logging I can collect and share for further examination?

Frequent Contributor

Re: bittorrent-like ftp client drops connection

You can run tcpdump (wireshark) on Windows (Wireshark · Download).

Switches in the GUI - there are two things you can do:

  • Enable connection debugging: Virtual Server > Connection Management > Connection Error Settings: enable log!client_connection_failures and log!server_connection_failures.  These settings will cause Stingray to log if a connection times out or is unexpectedly closed by the client or server
  • Enable analytics: System > Global Settings > Logging: set recent_conns to 200 (for example), then Virtual Server > Request Tracing: enable request_tracing!enabled

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.

Contributor

Re: bittorrent-like ftp client drops connection

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):

22/May/2013:11:16:21 -0400

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

Node             155.x.x.41:923

Local Port         38635

Rule     -

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

Response Code   

It never makes it pass 120MB transferred. Source: My desktop,  Destination: STM, Node: FFT server.

Contributor

Re: bittorrent-like ftp client drops connection

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

Contributor

Re: bittorrent-like ftp client drops connection

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