Angus Robertson

Bad URL, nothing more that can said. If you want real help, you need to give us real data. Angus

Which must be the result of code you have not shown, you need to use the debugger. You should build the OverbyteIcsHttpRestTst.dpr sample and try your URL using the GUI first. Angus

One possible reason is HTTP 1.0 does not support Keep-Alive, it should be 1.1. You are also setting a POST content type but using GET. That component added httpAuthBearer 18 months ago so you are probably using an old version. You would be better using the newer TSslHttpRest component that is much easier to use than THttpCli and has a new demo OverbyteIcsHttpRestTst.dpr designed for OAuth2. REST and Json. Angus

The FTPMulti component only use sync commands. Sure it will work with extra code to set the correct directory, but that code will be called anyway including creating directories if they don';t exist, with the correct parameters. Try the sample. Angus

Just tested 'Single FTP' upload using the ICS File Transfer Demo and it seems to work correctly. You should not need to set any component properties for paths, FtpUpOneFile uses the remote path specified there and correctly changes to the specified directory: > PWD < 257 "/" is current directory. > CWD /logs/testing/ < 250 CWD command successful. "/logs/testing" is current directory. > PWD < 257 "/logs/testing" is current directory. Uploading File, C:\tempfiles\regnam20.zip to /logs/testing/regnam20.zip, size 238 Kbytes Angus

If you want to do some ICS stress testing, you can use my ComCap5 and ComGen5 tools, the former is a general purpose data capture tool, the latter generates streams of TCP or UDP data to test the former. I tested ComGen5 creating 2,000 sessions to ComCap5, with 100 new connections per second (which is configurable) with ComCap5 saving data from all the connections into the same log file. Both tools use a single thread for all the connections. ComGen5 uses an array of TIcsIpStrmLog components to make the TCP client connections to TWSocketServer in ComCap5. SSL slows down the number of new connections per second, with about 300 out of 2,000 failing first time, but TIcsIpStrmLog retries failed connections so the session start on the next attempt. Angus

Yes, TWSocketServer has been tested with hundreds of clients, the main limit is how many new clients can connect each second, particularly with SSL which has a high connection overhead. Once connected, lots of large files can be download in parallel. But blocking the server with SQL requests, SHA1 sums, etc, will stop new connections, file I/O, etc, The ICS FTP server uses a thread for such operations. The ICS web and FTP servers are good examples, although quite complicated. Angus

I've not used FtpUpOneFile myself for many years, it was written for another client and worked in their circumstance, need to test it. Angus

There are new versions of the FTP client and server in SVN and the overnight zip, fixing the FTP server options being ignored and improving passive mode on the client. I've added logging for both client and server IPv4 passive mode to log various IP addresses before the data connection is opened, to make it easier to debug why a connection fails. The FTP client also has a new Option ftpFixPasvLanIP for when '227 Entering Passive Mode ()' returns a LAN IP instead of a WAN IP, so use control IP instead. This fixes failed downloads if the FTP server is behind a NAT router and is not configured to present the external IP. An example log is: > PASV < 227 Entering Passive Mode (192,168,1,161,82,10). ! Passive connection requested to: 192.168.1.161:21002, control channel: 217.146.115.83 ! Suspicious LAN IP changed to control channel address > LIST < 150 Opening data connection for directory list. www3.magsys.co.uk SSL Connected OK with TLSv1.2 < 226 File sent ok Note this example won't work now, I had to misconfigure the server to return the local IP address. Angus

Your three Xfer fixes are now in SVN and the overnight zip. Angus

The FTP server Options ftpsNoPasIpAddrInLAN and ftpsNoPasvIpAddrSameSubnetoptions were broken because the remote client IP was always returned as 0.0.0.0, now fixed, will be in SVN next week with other FTP changes. Angus

Sorry, I don't do C++ Builder, it needs peer support from other users. Angus

No, it gets an A rating and supports TLS/1,2 so should work with ICS. The OverbyteIcsHttpRestTst sample connects fine from here: www.kcsoftwares.com SSL Connected OK with TLSv1.2, cipher ECDHE-RSA-AES128-GCM-SHA256, key auth RSA, key exchange ECDH, encryption AESGCM(128), message auth AEAD Angus

SSL connections fail all the time for dozens of different reasons. The client might require protocols or ciphers the server does not support, or vice versa. Much depends on how the SslContext is set-up, it's easier on modern components like TSslHttpRest that do most of the hard work for you. If it's an obscure server, bad SSL configuration is always a possibility and https://www.ssllabs.com/ssltest/ is always useful to find how good or bad the server really is. Angus

Misconfiguration of NAT'd FTP servers is common, I only corrected one of mine this week. So if the client can help, it's worth a little effort. The STUN protocol allow determination of public IP address behind NAT, and a STUN component has been on my ICS wish list for a few years, maybe I'll finally write it. Won't help me though, since my development servers behind NAT have several different IPv4 and IPv6 addresses on two different ISPs. Angus

Yes this issue was discussed here last week relating to the ICS FTP server behind a NAT router. In the past, routers were able to manipulate the control channel to change the private IP address to public, but it seems FTP is now considered a legacy protocol and newer routers don't bother. Also SSL stops the router seeing the control channel, one reason you can configure SSL on data but leave the control channel clear. I like FileZilla's idea of re-using the earlier public address, I'll have a look and see if that can be done in ICS, as an option. Angus

On my list. Angus

TriggerDataAvailable was never designed to be extendable. Apart from the three version in wsocket no other ICS units override it. So while you can override it, you need to replicate all the functionality like parsing line endings. Angus

Yes, I was being lazy and hoping no-one would use that feature on Delphi 7, I'll add your fix next week. Angus

The ICS library is designed to be used through event handlers, not by overriding internal functions. That requires a high level understanding of the library structure and is beyond the support I can offer here. Angus

I am not trying to write your code for you, just explaining why your function does not work. You have a conceptual issue trying to override library functionality. Angus

You are not using the Inherited code in other versions of TriggerDataAvailable so need to handle line mode yourself. Angus

When using LineMode, in the onDataAvailable event you use ReceiveStrA to get a complete raw line without needing to check line endings, but that just calls Receive and does all the hard work for you. If you are creating descendent components, you need to ensure the correct ancestor, which is not easy due to the deep hierarchy of wsocket. LineMode is handled in TCustomLineWSocket. Angus

You just ignore errors you don't want to handle. Not a good idea though. Angus

This depends on whether you are connecting synchronously or asynchronously. For sync, a simple loop is all that is needed, but your loop will be blocked for up to a minute during each connection attempt depending on TCP/IP timeouts, look at function FtpLogon in OverbyteIcsFtpMulti which does this for different IP addresses. For async, you use the onSessionConnected event which is called whether a connection is OK or fails. Look at SocketSessionConnected in OverbyteIcsIpStreamLog which handles retries after a delay. Angus