Interesting reply.I apologize for being insensitive or touchy.
My argument was about products not people, any identification between them was unintended, but I had to ask *somebody* knowledgeable, and I did so offline, so as not to pollute the list. Since an all-out flame is not what a public list wants, I'll do everything I can to avoid this kind of reaction, while still making it known that significant problems and workarounds are in unresolved tension.
I think my prior post was too strong, let's keep only the data portion of it. This is what I know:
1 - Of 217 tests performed with FTP functionality in MC, in succession, about 40 worked without incident. They were small text files.
2 - The error rate appears to increase when multiple files are sent, or when there is more than 2 or 3 FTP calls per invocation of MC.
3 - Another member's post stating that Quitting MC fixes the problem is also corroborated by my experience.
4 - The following is beneficial for FTP robustness:
if not (the stacksinUse contains "libURL") then start using "liburl"
set socketTimeoutinterval to 100000
send "resetAll" to stack "libURL"
but we should understand that resetAll immediately closes open sockets, which may trunc pending writes or reads.
5 - the HTTP functionality of libURL has worked 100% of the time.
*** This is what I believe:
1 - If you have FTP needs, particularly for single transmissions, then the probability is that libURL will work very well.
2 - If the FTP client goes offline (I deploy on a network of computers in NYC, NJ, Massacusetts, and California), for instance, when a DSL or gateway connection is lost, the user will not know, but libURL should.
3 - Metacard *is* a fantastic tool. I have no idea what the support structure is, or what we can expect when lingering questions arise.
4 - Metacard has an address ([EMAIL PROTECTED]) which is accessible for support questions. It seems that Scott Raney is the person who answers from there, and perhaps that's a better venue for technical questions.
I retract the request for an FAQ for MC FTP usage. I'll take responsibility for that, and it will be as accurate only as I can make it. Whoever is interested in the URL for it, let me know.
Andu's angry reply correctly points out inaccuracies in my statements - I'm not an expert with libURL. It is why I asked for help.
I don't know who is responsible for libURL, or if it is a volunteered stack. If the latter is the case, I doubly apologize -- it was not common knowledge. I thought it was part of v2.4. But if libURL was goodwill work, its authors certainly deserve more forbearance than I've given them, despite any reliability issues. I don't even know who authored it.
I don't mean this as an insult to anyone: Why don't we create a thread for FTP users, so we can identify and focus on dialogue relevant to specific details with consistency problems? For myself, I won't flame or ignore anyone's email.
Cheers to all, and apologies to Andu.
andu <[EMAIL PROTECTED]> wrote:
>
> Contradiction please. Dennie is *correct* in pointing out prevalent and irritating performance irregularities with libURL.
>
> I too have had great hopes for MC FTP, but after hundreds of tests, can confirm only too well exactly the same results. More disheartening is that one
> week ago, I sent the same information to a prominent member of this list, going so far as to ask for an MC FTP FAQ. The plea has been ignored.
So you are pissed I didn't get to answer your email. I would've done it
instantly have I known you were so touchy.
Let me get something straight to you in case you didn't notice, I spent
many hours on this list helping people out with different matters
related to sockets, protocols, syntax and so on and I did it out of
pleasure not obligation. A good part of your unanswered mail deals with
syntax related to reading fi! les not ftp, although I will provide
instructions for whatever the library does, I will not make it my job to
jump on every bad syntax issue and bring light to the masses with a FAQ.
There is documentation for reading/writing files, if people invent their
own syntax, let them.
The library has been in testing as long as MC 2.4 has, most of the
issues brought to my attention were related to HTTP and I tried dealing
with them as fast as I could.
People discovered ftp in the past 3 weeks or so and again, I fix bugs as
soon as they are found, by me or others. Some bugs I can't fix because I
can't reproduce them.
You went "so far as to ask for an MC FTP FAQ". What is that supposed to
mean?
> From
> prior experience with PERL socket programming, I've tried scripting defensive safeguards and checks in libURL, but it just as often fails surreptitiously.
> Many questions have arisen in this list over MC's FTP irregularities. As s! omeone who has spent too much time fighting it, my challenge is that this code
> should be stabilized, and clarified via FAQ, or brought back into the shop as not being ready for production use.
You stabilize and clarify your code via FAQ, I'll let mine out to be
tested and bug reported. Be convinced, I do my testing with as many
servers as I can find, but real world tests with all kinds of
connections (or non connections) and servers will be more valuable to
everyone than a FAQ, as you imagine it. It is my expectation of libURL
to be of production quality and I'm fully aware it still needs work and
mostly constructive testing.
>
> The most successful corrective measures I have taken are (a) to increase the socketTimeoutInterval from the default 10000 millisecondsto a larger
> number, like 50000; and (b) to invoke libURL's "resetAll" handler before the next PUT URL or GET... URL transfer request. ResetAll closes all socket! s
> -- a drastic measure and one that improved my chances of success only moderately.
>
> As for the first problem -- timeouts -- it is common in FTP implementations that the connection can close before all data is sent. Sometimes the close
> on the data socket returns before all data are from the TCP socket are sent, and as ftp remote server receives a new command on the FTP command
> socket it closes the data socket, thus truncating the file.
I never experienced the communality of ftp servers closing connections
as you did but I agree error handling needs more work.
>
> libURL's error handling routines are naive. The socketError call, for instance, which is supposed to be invoked on errors, assumes that one can't open
> the connection *only* if the result sent to it is the string "Error 111 reading socket", rather than a more general failure condition. This means that all
> other return codes not exactly! equal to this string (and FTP flavors are free to implement their own strings) will go undetected. For its own part the
> socketError handler is never called inside libURL. At least the "try" control structure should be implemented to catch any realtime errors, regardless of
> origin. It is never used in the 1400+ lines of libURL stack script.
This one you got wrong, the error you mention is a socket error I
receive from the engine not ftp. Why should it be "called" and by whom?
Shall I make up stories so as to protect the sensibilities of some
users?
>
> On the same topic, the error diagnostics libURL produces are often inaccurate. If you have a valid url such as
> "ftp://user1202:[EMAIL PROTECTED]" but your net connection is down (or perhaps your laptop in Starbucks isn't on the Net), libURL responds to
> a failed connection with the spurious "invalid URL" message that will throw off any deeper error processing.! The list of problems goes on.
My mistake, I assumed I should provide error messages for computers
connected to the internet but you convinced me, people do try to use ftp
without a connection and I should consider them too.
>50-80% of the
> time, the code works 100% well. The rest of the time, it works erratically. If you only use it once in a while, the odds of success are in your favor.
>
> In my experience, this library and its functionality, much touted in version 2.4, is undertested and undersupported. It's not hard to test FTP -- it's very
> easy in fact -- but it has to be done in volume under pessimistic scenarios (large file sizes; diverse FTP server environment). None of my tests used
> files larger than 25K of text. The FTP server (Compaq Proliant running Linux) works through other attempts, so I rule it out Besides, if it fails, the client
> should still know and warn the user. Real QA would be advised f! or the next release and as implemented, and as for critical data transfers, libURL has a
> credibility problem.
Oh boy, oh boy, like old Bush used to say, if you don't have something
good to say, say something bad. Send in those bug reports, rather.
>
Andu
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Francisco J. Ricardo, Ph.D.
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. Yahoo! by Phone.
