FTP Control does not detect interrupt ?

[Gary Maxwell]

We are running a VB 6.0 Script using the SocketTools 5.0 FTP control to transfer a file to a client's FTP server.

In the script we execute the FTP.PutFile method to copy the file to the server.

Occasionally, according to the client, they are seeing an interrupt in the FTP logs. This results in a 0 byte file being written to their server.

What is puzzling is that

a) the SocketTools control does not report an error.
b) the interrupt is followed by a new FTP login (different process id). This is NOT as a direct consequence of
any explicit instruction in the VBScript (some of the characteristics are different).

Questions ?

Why hasn't SocketTools detected the interrupt ?
How does SocketTools deal with these things ?
Could an interrupt force a new (cached) login ?

[Technical Support]

This is related to your other post, so I'll follow up here. What you're seeing is a feature in the control where it's seeing the server abort the data channel connection and it's automatically attempting to recover by reconnecting to the server (authenticating again using the same credentials, changing to the current working directory, etc.) This was implemented to handle situations where a data transfer would complete, but the server would not gracefully disconnect the data connection and leave the client session out of sync. It's one of those "working as designed" situations where the control is trying to preserve the client session, but may actually be more useful to return an error code. This behavior is hard-wired into the code that deals with closing the data channel, but we've made some changes in the next update so that it's a bit more selective about when it chooses to do this.

[Gary Maxwell]

Thanks for clearing that up Mike. I believe we started experiencing this when we went migrated from 3.6 to 5.0 so do the two version differ in thie respect?

[Gary Maxwell]

Mike,

One further question - you say this was implemented to handle situations where a data transfer would complete but the server would not gracefully disconnect the data connection. In this scenario the transfer doesn't complete (ie. we deliver a 0 byte file) - so is this behviour still expected. Thanks.

[Technical Support]

The feature was added in 4.0 or 4.5 as I recall, so it's been around for a while but it didn't exist in the 3.x versions. It the service pack update which will be available on Wednesday, we've changed it to be more selective about when it attempts to resync with the server. Currently, any error will trigger the attempt to resync; in the upcoming version, that will only happen if we get an unexpected response from the server on the command channel in response to the file transfer completing (in other words, we're basically getting garbage on the command channel because somehow the client and the server have gotten out of sync with one another). Explicit failures (i.e.: access denied, quota exceeded, etc. types of errors) will be passed back up to the application, as well as situations in which the connection has been aborted by the server.

This resync feature is something that's come up on the radar with a number of developers, and in discussing it, we feel that although the attempt to automatically recover the client sessions is a good thing in general, doing too much "behind the scenes" and out of the direct control of the developer isn't a good thing. So we've come down on the side of things where we're going to be much more conservative about when to resync, and in most cases if something goes wrong, then it's going to be the responsibility of the application to deal with it.

[Gary Maxwell]

Mike. Thanks for your valuable input.

[Gary Maxwell]

Mike, is the service pack update referred to available & if so how can we obtain it.

Thanks,
Gary

[Technical Support]

It's available, and you can simply go to our main site and re-download your product. I'd recommend uninstalling your older version before installing the new version.

[Gary Maxwell]

On this thread, I've enabled tracing to try & ascertain why we're getting a disconnect in the first place.

On issuing the FTP.Putfile command we see the following at the end of the transfer (ip address replaced for obvious reasons):

1670 30 35 30 30 30 31 0D 0A:55 54 4C 31 30 30 30 30 050001..UTL10000
1680 30 30 35 38 32 37 30 35:35 30 30 30 30 36 34 31 0058270550000641
1690 20 20 20 20 20 20 20 20:20 20 20 20 20 20 20 20
16A0 20 20 20 20 20 20 20 20:20 20 20 20 20 20 20 20
16B0 20 20 0D 0A ..
CSCRIPT 215358 0000 INF: closesocket(476) returned 0
CSCRIPT 215458 60000 INF: select(64, 0x13e14c, 0x0, 0x0, 60:0) returned 0
CSCRIPT 215458 0000 INF: closesocket(480) returned 0
CSCRIPT 215458 0000 INF: socket(2, 1, 0) returned 480
CSCRIPT 215458 0000 WRN: connect(480, 99.99.99.99:21, 16) returned -1 [10035]
CSCRIPT 215458 0000 INF: select(64, 0x0, 0x13dfc4, 0x0, 60:0) returned 1
CSCRIPT 215501 3016 INF: select(64, 0x13de00, 0x0, 0x0, 60:0) returned 1
CSCRIPT 215501 0000 INF: recv(480, 0x13df28, 1, 0) returned 1 0000 32 2
CSCRIPT 215501 0000 INF: select(64, 0x13de00, 0x0, 0x0, 60:0) returned 1
CSCRIPT 215501 0000 INF: recv(480, 0x13df29, 1, 0) returned 1
0000 32 2
CSCRIPT 215501 0000 INF: select(64, 0x13de00, 0x0, 0x0, 60:0) returned 1
CSCRIPT 215501 0000 INF: recv(480, 0x13df2a, 1, 0) returned 1
0000 30 0
CSCRIPT 215501 0000 INF: select(64, 0x13de00, 0x0, 0x0, 60:0) returned 1
CSCRIPT 215501 0000 INF: recv(480, 0x13df2b, 1, 0) returned 1
0000 2D -

I'm not sure if there's anything significant in this detail.

When the transfer is retried successfully sometime later:

1660 36 37 36 20 35 32 30 31:33 36 35 30 34 30 32 31 676 520136504021
1670 30 35 30 30 30 31 0D 0A:55 54 4C 31 30 30 30 30 050001..UTL10000
1680 30 30 35 38 32 37 30 35:35 30 30 30 30 36 34 31 0058270550000641
1690 20 20 20 20 20 20 20 20:20 20 20 20 20 20 20 20
16A0 20 20 20 20 20 20 20 20:20 20 20 20 20 20 20 20
16B0 20 20 0D 0A
CSCRIPT 230437 0000 INF: closesocket(500) returned 0
CSCRIPT 230437 0000 INF: select(64, 0x13e14c, 0x0, 0x0, 60:0) returned 1
CSCRIPT 230437 0000 INF: recv(508, 0x13e274, 1, 0) returned 1
0000 32 2
CSCRIPT 230437 0000 INF: select(64, 0x13e14c, 0x0, 0x0, 60:0) returned 1
CSCRIPT 230437 0000 INF: recv(508, 0x13e275, 1, 0) returned 1
0000 32 2
CSCRIPT 230437 0000 INF: select(64, 0x13e14c, 0x0, 0x0, 60:0) returned 1
CSCRIPT 230437 0000 INF: recv(508, 0x13e276, 1, 0) returned 1
0000 36 6
CSCRIPT 230437 0000 INF: select(64, 0x13e14c, 0x0, 0x0, 60:0) returned 1
CSCRIPT 230437 0000 INF: recv(508, 0x13e277, 1, 0) returned 1
0000 20

[Technical Support]

From what I can tell, the server is returning two different success result codes but that in of itself shouldn't really make a difference. As long as we see a result code that's indicates success (i.e.: in the range of 200-299) then we consider the transfer completed. Is this something that's only happening with a particular server, or are you experiencing this problem against multiple servers?

[Gary Maxwell]

We're only seeing it on one particular server. The strange thing is that the trace would appear to indicate that the file has transferred in it's entirety (I see the last line of the file in the log) yet we get a 0 byte file written on the server. Whatever happens provokes the FTP control to automatically reconnect. I'm convinced that it's a problem with the third party server.