Transfer Queue trying to use disconnected session

Buoysel

2008-11-28 00:05:52

mb

2008-11-28 00:14:19

The Transfer Queue already ignores disconnected connections but if the server does not send the SYN packet to close the connection the client (SmartFTP) doesn't know that the connection is closed before it sends a command.

Buoysel

2008-11-28 00:28:51

mb

2008-11-28 00:32:42

Where do you see the following error? In the Remote Browser or in the log of a transfer queue item?
[23:07:28] 421 No transfer timeout (600 seconds): closing control connection
[23:07:28] Server closed connection

In this case the server actually disconnects the client and there should be no problem.

Regards,
Mat

Buoysel

2008-11-28 00:36:04

Where do you see the following error? In the Remote Browser or in the log of a transfer queue item?
[23:07:28] 421 No transfer timeout (600 seconds): closing control connection
[23:07:28] Server closed connection

In this case the server actually disconnects the client and there should be no problem.

Regards,
Mat
Ah, that's from the Remote Browser.
Yeah, whenever it looks like this, the Transfer Queue seems to have no problem.

I see "Server closed connection" for both the good and the bad disconnect, though. Wouldn't it be possible for SmartFTP to use this event instead of the "421" event?

mb

2008-11-28 00:47:03

I don't understand what you mean. The server sends the 421 etc error or something similar. My assumption is that the client never receives this reply. But if it does it probably also gets the TCP close.

Buoysel

2008-11-28 00:51:27

mb

2008-11-28 01:21:23

In your 2nd example:

[00:26:24] 200 NOOP command successful
[00:27:14] PWD
[00:27:15] Eine bestehende Verbindung wurde softwaregesteuert


It knows it AFTER the PWD command has been sent and not before.

I don't know where the NOOP command is coming from. Did you get this log from the Remote Browser? In this case the log is irrelevant.

Buoysel

2008-11-28 02:04:09

Yes, it is from the Remote Browser.
NOOP and PWD are in my "Keep Alive" command list.

So I guess SmartFTP will not be updated? Reconnecting right away when this happens is not possible? Ignoring the Remote Browser connection for the Transfer Queue completely is not possible?

mb

2008-11-28 02:41:25

The Remote Browser connection is already independent from the Transfer Queue.

Buoysel

2008-11-28 12:47:25

Okay.

[13:43:42] SIZE xyz.rar
[13:43:42] Eine bestehende Verbindung wurde softwaregesteuert
[13:43:42] durch den Hostcomputer abgebrochen.
[13:43:42] Transfer failed.
(That's ALL of the log.)

So, is there anything I can do, so I do not have to wait forever whenever this happens? I don't know the cause of it and there's nothing I can change in my server configuration. It doesn't happen with FTP clients other than SmartFTP.

mb

2008-11-28 13:31:26

The problem as explained before is that the client (SmartFTP) never receives the disconnect from the server. If you have a proper network configuration you would not see the problem. You can decreaes the retry delay to 1 second.

Buoysel

2008-11-28 18:27:39

Image
I found this option and disabled it. I hope this will fix the issue...

mb

2008-11-28 21:08:28

It is not recommended to disable this option but disabling it will work around the problem you have. But it's certainly not the best way to fix the problem.

Buoysel

2008-11-28 21:13:50

Well, it does seem to be the only way for me, doesn't it?
I don't know how my network configuration might not be "proper".

mb

2008-12-02 23:53:15

Do you see this kind of disconnect in the transfer queue only? How about in the Remote Browser? Does it say there for this particular server "server disconnected"?