Angus Robertson

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

Does seem strange the code eats errors on OnDataAvailable silently while some other events do raise an exception. I've updated my version to trigger a background exception, but this change is not absolutely backward compatible, applications that don't have OnBgException assigned will now shut down with an exception window, rather than perhaps continuing to ignore the error, maybe good, maybe bad. This won't go into SVN for a few days, until I've rebuilt and tested all my applications. Angus

If multicast needs to listen on multiple UDP ports and/or addresses, just create an array of TWSocket components with different IP addresses/ports for each, sharing the same event handlers. For TCP we already have TMultiListenWSocketServer which is the same as TWSocketServer so web servers listen on lots of ports and IPv4 and IPv6 at the same time. Angus

There are two names for contributors that worked on multicast in the release notes, but they were almost 20 years ago. Angus

I just use a simple batch file: cd C:\Program Files (x86)\Windows Kits\10\bin\x86 signtool sign /p "password" /f "c:\certificates\magenta-systems-certkey.pfx" /d "WebApp Server - Telecom" /fd sha1 /t http://timestamp.verisign.com/scripts/timstamp.dll "d:\webapps\webapp_telecom.exe" signtool sign /p "password" /f "c:\certificates\magenta-systems-certkey.pfx" /d "WebApp Server - Telecom" /as /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp "d:\webapps\webapp_telecom.exe" signtool verify /all /pa d:\webapps\webapp_telecom.exe This assumes you can buy a code signing certificate as a file, some authorities only sell them on dongles when you need a slightly different command line and you may find Windows demands a password each time you sign a file, so not very automated. EV certificates are only needed for kernel drivers. If you start your order at https://msdn.microsoft.com/windows/hardware/drivers/dashboard/get-a-code-signing-certificate you will find most authorities offer substantially cheaper prices than their web sites, Digicert sells EV for $104 a year, non-EV for $74. Angus

Sorry can not really help any further, I think my last UDP project was just broadcasting not multicasting. I would test keeping things simple, ignore multicast completely, just a simple UDP listener and see what happens. Your can use the OverbyteIcsIpStmLogTst sample to send normal UDP packets to make sure your server is receiving something, then look into why multicast is not working. Angus