zipped
files which where unzipped. unfortunately Bluecoat failed with a
certain size of file and as seen from the user, the transfer
failed.
Once that Bluecoat feature was turned off, everything went OK.
That does not explain why it works with ICSv5.
The firewall may have been
Hello Francois,
FP That remind me a site where a bluecoat system was installed. Bluecoat was
FP configured to scan for virus any file passing thru, even zipped files which
FP where unzipped. unfortunately Bluecoat failed with a certain size of file
FP and as seen from the user, the transfer
Hello Francois,
OK, after another series of tests it turned out that I have no idea
what the problem is. The user could find out that:
- using a passive connection to transfer any file of a certain size
(maybe larger than 38Mb but maybe 37.Mb) causes a failure under
unknown
OK, after another series of tests it turned out that I have no idea
what the problem is. The user could find out that:
- using a passive connection to transfer any file of a certain size
(maybe larger than 38Mb but maybe 37.Mb) causes a failure under
unknown conditions (the ftp
Hello Arno,
No, it was reported that the software with FTPCLI_BUFFER_OLD also
hangs :(
Monday, January 24, 2011, 10:30:29 AM, you wrote:
AG const
AG // BLOCK_SIZE = 1460; { 1514 - TCP header size }
AG {$IFDEF FTPCLI_BUFFER_OLD}
AG FTP_SND_BUF_SIZE = 1460; { arno V7.18 }
AG
Antol wrote:
Hello Arno,
No, it was reported that the software with FTPCLI_BUFFER_OLD also
hangs :(
That's sad news :(
I'm running out of ideas, anybody else?
--
Arno Garrels
Monday, January 24, 2011, 10:30:29 AM, you wrote:
const
// BLOCK_SIZE = 1460; { 1514 -
I'm running out of ideas, anybody else?
Is it confirmed that the server actually send the 226 answer and this is
lost because the client doesn't see it ?
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component
Hello Francois,
By the moment the software was tested with 2 servers, and the behavior
is the same. We could think that the router is the problem, but the
only unexplained thing remained is why ICS5 works...
Thursday, February 3, 2011, 9:19:16 PM, you wrote:
I'm running out of ideas,
FP Is it confirmed that the server actually send the 226 answer and this is
FP lost because the client doesn't see it ?
By the moment the software was tested with 2 servers, and the behavior
is the same. We could think that the router is the problem, but the
only unexplained thing remained
Hello Francois,
Thursday, February 3, 2011, 11:03:36 PM, you wrote:
FP You said you reproduced the issue with your own server being interrogated,
FP so it should be easy for you to spy on the network at your own server and
FP see if the 226 answer is properly sent with his ending CR/LF.
No,
Hello Arno,
Friday, January 21, 2011, 8:51:33 PM, you wrote:
AG My first guess is that it is a server issue. The server has to send a
AG response on the control socket, either success or failure.
AG Or for some reason that response was sent however doesn't get thru?
AG If you can get a RDP
Antol,
We realy need a reproducible test case. I searched the source
again but was not able to find a change that could lead to the
problem. Double check that you use latest ICSv7 from:
http://wiki.overbyte.be/wiki/index.php/ICS_Download
My OverbyteIcsFtpCli.pas is V7.17
--
Arno Garrels
Hello Arno,
Sunday, January 23, 2011, 10:09:00 PM, you wrote:
AG Antol,
AG We realy need a reproducible test case. I searched the source
AG again but was not able to find a change that could lead to the
AG problem. Double check that you use latest ICSv7 from:
AG
support mailing
Subject: Re: [twsocket] FTPCli problem.
Hello Arno,
Sunday, January 23, 2011, 10:09:00 PM, you wrote:
AG Antol,
AG We realy need a reproducible test case. I searched the source
AG again but was not able to find a change that could lead to the
AG problem. Double check that you use
Antol,
We realy need a reproducible test case. I searched the source
again but was not able to find a change that could lead to the
problem. Double check that you use latest ICSv7 from:
http://wiki.overbyte.be/wiki/index.php/ICS_Download
My OverbyteIcsFtpCli.pas is V7.17
No, it is
Additional information: it is supposed that the problem happens in
passive mode only.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Antol wrote:
So, the difference is that on the problematic PC the line
15:13:40:061 |226 Transfer complete|
is not always received or processed properly. What is the reason and
how to fix this?
My first guess is that it is a server issue. The server has to send a
response on the
Hello Twsocket,
I use the latest ICS v7 distributive. The problem happens on [not
my] WinXP system with slow DSL connection. I cannot
reproduce it on other PCs, so I gave that user a special version that
writes logs to file. The problem is as follows: when the file is
completely
Hello All
I have an application that use FTPCLI to fetch some files from a server. Async
is used. It runs on a number of PC's. On a single PC running XP I sometimes
have trouble quiting from a FTP server (WEB6 Microsoft FTP Service (Version
5)). The ICS version used was downloaded the 9/3-05 -
19 matches
Mail list logo
