SO_LINGER Option

Question

This relates to a problem we were having back in early May. I rejoindered on a forum thread here where Lukas kindly answered. I didn't hear back so I checked and there is a new release (I just downloaded and installed) that has exactly the option we were seeking listed in the Delta Document for 3793. I'm trying to find that option in the FTPOptions class but it's not jumping out at me. There are a couple of options I did find that will be useful, but we really need Linger to work due to the fact that our software has to perform over some really crappy networks in the field. Setting this option in our own protocol handlers solved exactly the sort of early-disconnect problem we were having in our own protocols as is referenced in the forum question at the link.

Thanks again. We really like this product. Other than that occasional ill-behaved early disconnect that reports an error even when a file has successfully been uploaded, the product works very well for us.

James World Information Systems, LLC Greensboro, NC

Answer 1

We assumed (not sure why now) that this issue you were having was only present when .NET Compact Framework version of Rebex FTP was used on a Windows CE/Windows Mobile device. Since Rebex FTP 3.0.3079.0, we always enable SO_LINGER in .NET Compact Framework build.

Should we add an option to enable SO_LINGER in the .NET build as well? There would be a new option in FtpOptions enum for that.

Comments

In that case, that option alone isn't solving our problem. Indeed, the problem appears only on CE/Mobile Devices. To reiterate, this problem occurs when there appears to be a FIN and a RST bit set on a final upload packet. This causes the host to obey the RST and reset the connection which in turn causes the FTP client to throw a very messy exception. This exception blows the call stack all the way up to the top-most instantiating object and the entire app crashes. The device must be warm started. Enclosing the FTP object method call in a Try/Catch does not catch the exception.

---

(continued) We solved a similar problem in our own proprietary protocol first by catching several kinds of exception (a general system exception does NOT always catch all exceptions) and always delaying socket close by at least 250ms. Our experience indicates that "by the book" coding of Dot Net socket objects lends flaky and very optimistic code at best. Our customers have some really very awful networks, requiring a lot of bullet-proofing. The CF doesn't give one much to work with, but it is possible. Again, you may email me for particulars and snippets.

---

I sent you an e-mail on June 24th, have you received it?