Angus Robertson

The change to report exceptions rather than hide them is now in SVN. Angus

It is never a good ideal in high performance application to update a visual component like TMemo, scrolling the screen is expensive for heavy updates and will slow down or even stall your application, likewise calling Synchronous to do that stops your thread. I've been slowly updating ICS samples like OverbyteIcsIpStmLogTst1.pas so that log lines build a string buffer which is written to a TMeno from a timer every one or two seconds which is fine for most purposes. It is better to use Windows messages or even a socket to send logging to the main thread, effectively they become a non-blocking queue. Our tests with ICS indicate a single thread will handle at least two hundred simultaneous requests, provided don't block with SQL or start doing massive MD5sums or other horrible stuff. If you look at the OverbyteIcsMailQueue.pas unit, that has a thread to send emails from a queue, updating by the main thread, and shows how to use a message handler while the thread is waiting to do something. However if your thread only makes continual sync Post requests, you might get away without a specific message handler because ICS calls one itself waiting for the request to finish. But I'd still suggest creating an array of 10, 50, etc, TSslHttpCli all sharing the same event handlers, use Tag to identify which is calling an event and test that. This just works. Angus

Why do you need to run 10 threads, instead of 10 instances of TSslHttpCli in a single thread. That is how you use Indy which is blocking, not ICS which is none-blocking mostly. I would first ensure none of your threads access any visual components and ideally don't use Synchronize atall. I don't see a message loop anywhere in your thread, so nothing should work. You can use blocking calls in a thread, since it's doing nothing else. And a thread may be necessary if you are doing long processing like SQL database look-ups, although even then it's better to use a thread for only the SQL stuff and leave all ICS stuff in the main thread. Angus

Never seen the icon lost, been signing files for 15 years. Are you using the latest signtool? No other EXE manglers? Angus

Most better ICS applications use Async methods so are fully event driven, allowing multiple connections are the same time in a single thread. So most of the code goes in various event But sync calls are easier to use from a program flow perspective and the code can either be in the event are after the sync call, although exceptions cause trouble which is why I added ResponseNoException. But sync programs are less suited to multiple connections or tasks at the same time. In event driven applications, you usually use messages from an event to start something new or a triggers in a timer event to start another connection 60 seconds later of something, I do that a lot. Angus

It is better to process the response in the onRequestDone event. There is a new property added a year ago ResponseNoException which will help you. Angus

Don't know what FConnectorUtils.StreamToString does, but you always have to seek to beginning of the stream before reading it. There is a new function that convert an HTML page in the buffer to unicode string with the correct codepage: FResponseRaw := IcsHtmlToStr(FResponseStream, FContentType, true); Last boolean option converts HTML entries like £ and ☍ to unicode. That function is used in the new TSslHttpRest unit that hides a lot of the low level stuff you are doing returning Json. Angus

I don't run Windows Firewall anywhere, and still see rare problems, thus the retries. Adding your EXE to the exception list may help, but not be a complete solution. Angus

Sorry, no simple answer, the issue might also relate to NAT translation in a router somewhere, which has to keep track of all the sessions. I had a Netgear router in the early days of broadband that could not handle more than one file per session. While TIcsFtpMulti retries individual files on error, once the control connection dies nothing works, but my higher level application then retries the whole job. This happens with non-SSL as well. As I said, never got the bottom of it, just have to cope with the errors. Angus

Problems like that are hard to track down, could be client or server, perhaps something to do with SSL session caching since each new file opens a new SSL connection. Trying to debug is almost impossible due to the volume of data created after 145 files. You can try other clients to the server, or your client to a different server, you can test against the ICS FTP server on one of my pubic servers. I download hundreds of log files daily from those servers using FTP and errors are very rare. But I use the new (to ICS) TIcsFtpMulti component and that does automatic retries if a file download or upload fails. Angus

I've asked the author to comment. The Connect methods are inherited, often something happens where you don't expect it. Angus

Unfortunately the developer that added SocketFamily and IPv6 never documented it's intended external use. I've been adding SocketFamily into more components and samples recently now I have IPv6 on all my local and hosted servers, firewall support for IPv6 is in it's infancy and stopped IPv6 working for a long time. I've been finding DNS lookups may offer an IPv6 address which then fails to connect for various reasons, so you need the ensure SocketFamily is set to sfIPv4 to the alternate IPv4 is used instead. But that is all done automatically, so not sure that family checking is necessary for proxies, if it's done later anyway. Angus

I suspect those two checks are unnecessary, should I just remove them? Or will it break use of IP addresses? Angus

Not looked closely, but in ICS setting SocketFamily to sfAny is the common way to avoid IP address checks. But there were some changes by a contributor in V8.56 to support IPv6 with proxies, so maybe something got broken. Angus

While it always good for people to test SVN trunk, it is a work in progress and not designed for production use, at least unless there have been no changes for several weeks and it's been released properly released. Having said that, I try to built all my live applications before uploading anything to SVN, and build all packages and a few samples with Delphi 2007 and the latest version. A bad web server did slip out a couple of weeks ago that I forget to put on my own hosted servers and once I did an SSL certificate issue became apparent, but that is very rare. But that panic update was the cause of your TriggerSslAlpnSelect issue, and I'm still messing with it today. It will be sorted real soon, but may not reach SVN for a few days. Stuff like USE_SSL and packages for all compilers only gets tested before a final release. Angus

Testing without USE_SSL is very low priority, most improvements to ICS involve SSL so you may as well use an old version. Improvements are always made so that USE_SSL is still honoured, nut new units are skipped completely since all new development assumes SSL is used. But I will do a quick test of V8.62 before it is released, however too many errors may mean that and future versions become SSL only, I'm not spending time to make it 100% backward compatible. Angus

Done, had a problem copying hidden unicode characters from this forum. Angus

OK, soon. Angus

Accessing Delphi objects from C# is very unusual, was not aware it could be done. It's certainly not something we can support here. You would presumably need c# headers as well, or whatever than language uses. Creating DLLs using ICS is common, there are examples in samples, but they export complete functions, not the components themselves and always use a thread with a message handler. Angus

So you have lost the ICS source code for your old dpr? But not the DLL itself, so you can check to see what exports you created and replicate it for your new DLL. You should not need our help. Angus

Do you mean the exports are not in the DLL, you can use a DLL exports viewer to check that. the Windows Kit has one, lots of others around. For a DLL, you need a library dpr with an exports section, which I assume you created yourself. It may need updating with changes over many years. Or perhaps you are only exporting functions you wrote, and not the entire library? What version of ICS were you using before, in OverbyteIcsWSocket.pas? Angus

Pleased you got it working. Session caching is poorly documented in ICS, all written by a previous developer and I don't really understand it. But the new high level components I've added in the last couple of years like TIcsFtpMulti, TSslHttpRest and IcsHosts for servers, handle most the SSL implementation like SSL context and session caching, so the application does not need to worry about it, and that's why TIcsFtpMulti worked. Angus

There is a Websockets project at https://github.com/fajar-khairil/ics-websockets by Stan Korotky, dating back to 2012, but it is not SSL enabled. From the demo server comments: Basic websockets server based on TWSocketServer and TWSocketClient components, and websockets implementation ported from phpws project (http://code.google.com/p/phpws/). Derived from TCP server demo V7.02, by François PIETTE. Been meaning to incorporate it into ICS for a while, never had the time or a suitable project to test it with. Angus

I wrote the CSV component 20 years ago before TStringlist got more fancy. Angus

TStringlist has DelimitedText and CommaText properties that works for many CSV files, free and one line of code. However it treats spaces as a delimiter, so I use a minor variant that also always writes delimiters. Angus