Transfer Queue trying to use disconnected session

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.

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

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?

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.

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.

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?

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

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.

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.

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

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.

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

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"?