Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #42645 |

    Hoping someone here can explain what happens when a server timeouts from inactivity.

    Because my application can push a new file every couple of seconds, I try to avoid disconnecting/connecting if possible. However, some servers have very short inactivity timers and when a user configures the software to a push interval greater than the interval, the next push fails because the current control doesn’t realize the server timed out.

    Since most servers don’t tell you they timed out until you execute another command this may not be possible.

    Has anyone found a dependable workaround?

    -jason.

    Imported from legacy forums. Posted by Jason (had 5467 views)

    User (Old forums)
    Member
    Post count: 23064

    Hello Jason.

    You should normally receive the <B>Disconnected</B> event as soon as the server disconnects you.

    Imported from legacy forums. Posted by Martin (had 328 views)

    User (Old forums)
    Member
    Post count: 23064

    Martin, the problem I see is that many FTP servers don’t close the socket. They wait for you to try a command after the timeout and then they tell you that your connection has timed out from inactivity and you have to close and reopen the FTP connection (I think the socket can stay connected through this).

    This is very problematic in that there doesn’t appear to be a standard in the FTP protocol for this behaviour. So, it doesn’t bother me that the components wouldn’t have a way to detect when it happens. What I am looking for is a quick and easy way to determine if the FTP server has timed out before sending an important command that assumes the server is still accepting commands. Then if the simple command fails, I can have the program close and reopen the FTP connection before sending the important command.

    Is it simple to set the transfer type to binary or something like that and determine that the server accepted it?

    Thanks, your support has been very responsive!

    -jason.

    Imported from legacy forums. Posted by Jason (had 554 views)

    User (Old forums)
    Member
    Post count: 23064

    Hello Jason,

    You are right, this behavior is problematic, since we have no way to determine if the server has timed-out. And yes, you could send a “dummy” command before important commands. I would suggest you use the SendCommand method, that lets you send anything you wish to the FTP server. The command you should send is “NOOP”. Obviously, this is a “no operation” command, which the server should handle by either returning a success reply (then you’re still logged-in) or an error (the method will throw an appropriate error).

    If you wish to go further, you could set yourself a timer that checks if the XceedFtp instance’s CurrentState is “fstConnected” (which means it’s idle) and sends this NOOP command every N seconds to keep the connection alive. There may be some FTP servers that don’t consider NOOP as real activity, but it could work on most servers.

    Imported from legacy forums. Posted by Martin (had 376 views)

    User (Old forums)
    Member
    Post count: 23064

    I just downloaded the trial version and noticed in the release notes that you added the Keep Alive functionality. Thanks! This should simplify the logic in my code a bit!

    -jason.

    Imported from legacy forums. Posted by Jason (had 501 views)

    User (Old forums)
    Member
    Post count: 23064

    I just purchased a developer’s license. Great product! It only took about two hours to revamp my FTP class to use your control instead of the Microsoft Internet Transfer Control. Plus, it is many times more stable and shows no latency when running in asychronous mode.

    -jason.

    Imported from legacy forums. Posted by Jason (had 5984 views)

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.