Angus Robertson

Not strictly an ICS issue, but this topic is read by others as well. Reverse DNS lookup with IPv4 generally works well, most proper providers at least provide their main name even if the IP is not specially allocated, ie msnbot-157-55-39-2.search.msn.com. But IPv6 rDNS is much less useful, mainly because most addresses include 64-bit of effectively random data, which are added to the 64-bits of public address. So my public ranges are 2a00:1940:1:2 and 2a00:1940:2:2, but my remote address is today seen as 2a00:1940:1:2:ed4c:1a97:12fa:c6e7. I have reverse DNS for my public server addresses like 2a00:1940:2:2::139, but not the random ones. Some DNS servers seem able to look-up IPv6 addresses using just the public part of the address, like btcentralplus.com in the UK, but most don't. You can find the public name using Whois, but this is not designed for heavy use by a server looking up each new client that connects. One solution would seem to be a simple text file with the public names, even just the first 32-bits are enough, 2a00:1940 is Merula my hosting company, 2a02:c7f is BSkyB Broadband, 2a00:1450 is Google, etc. Has anyone found such a file? Any other thoughts on reverse DNS for IPv6? Angus

Sorry, there has been insufficient interest in webhooks to justify any further investigation with ICS. Presumably you want to write a webhook client? Exactly what webhook server do you want to access? Angus

Good, as ICS has developed over 20 years there are local functions like DirExists in various units, often duplicated and not always kept up to date, which I'm slowly concentrating in OverbyteUtils. Angus

The quick solution is to replace DirExists with SysUtils.DirectoryExists which is available in Unicode compilers, and which is already used in OverbyteUtils for IcsDirExistsW. I'll fix this in SVN shortly. Angus

Thanks, I'll try and test this next week. The API is documented as returning INVALID_FILE_ATTRIBUTES for failure, which we assume is -1, but maybe it's not. Angus

Easiest solution is to put a breakpoint in the CommandRNTO procedure and step through under the debugger to see which statement fails. There is nothing obvious that would fail on Win64. Angus

Probably a firewall on your cloud server, although it may be IIS is already listening on all IP addresses so traffic goes there instead. Generally better to listen on specific IP addresses, not all. If IIS needs to run, you need a registry patch so it only listens on specific IP addresses. Mind with modern cloud servers, you may only get one IP address. (mine has 30). Angus

The low level socket server does not include any timers, but the higher level HTTP and FTP server component do include various timeouts. TWSocket itself includes a TWSocketCounter class which descendents can check periodically with a timer to close idle connections, depending on activity. For HTTP, the procedure HeartBeatOnTimer checks whether a request is being processed and disconnects according for KeepAliveTimeSec or KeepAliveTimeXferSec. You could add something similar including checking whether SSL has been negotiated. If you are concerned about hacking attempts, I find it's actually better to leave connections open for a long time, doing nothing, which stops the remote robot doing anything else with that connection, close it immediately and it moves on to the next attack attempt. The OverbyteIcsSslMultiWebServ sample includes various hacking tests, and sends a response after a one minute delay. One test I added to my public web server is any access by IP address instead of host name, immediately onto the hackers list. This is also in a new sample I added yesterday, OverbyteIcsDDWebService, which is similar to OverbyteIcsSslMultiWebServ but runs as a real Windows service or a GUI for debugging). and includes a new database REST server sample. Angus

And how is this relevant to your UDP problems, is it working yet. Angus

For your broadcast socket, see what replies you receive in the onDataAvailable event, if any. Test it. The OverbyteIcsIpStmLogTst.dpr sample allows all this to be tested using the TIcsIpStrmLog component that does UDP client and server, only snag is a bug in the sample that meant UDP server alone did not listen correctly, fixed yesterday when I tested broadcasting, I'll put it in SVN shortly. Angus

LastError is generally set when a Windows API fails to that Windows error, but code is needed after every such function call, and was sometimes missing, for SendTo/6 in particular, now fixed. You must use Connect for broadcast to work. You should use a separate socket for listening. Angus

II think our messages overlapped. Angus

Further to my original message about using SendTo, for broadcasting or multicasting you must also set property Addr to the broadcast address before calling Connect, otherwise the socket will not be opened with the correct SO_BROADCAST flag. Send should also work, as used in various components and samples, but SendTo is required for UDP servers to reply to the source address, and works as well for clients. Angus

Your partial code looks okay. TCP Send and related functions simply stuff data in a buffer with no real error, SendTo sends UDP immediately with a Windows API but unfortunately does not get the real error (which Send already does for TCP). If you get back -1 from SendTo, use LastError := WSocket_Synchronized_WSAGetLastError; then WSocketErrorDesc to get a message, I'll correct this in SVN for V8.67, not sure how it got missed for 20 years, but UDP rarely fails, or at least rarely gives errors, you have no idea if packets are received anywhere. Angus

UDP is connectionless protocol, connect does nothing, you use SendTo and SendTo6 to send UDP packets setting the address and port in a TSockAddrIn or TSockAddrIn6 structure. When receiving, in onDataAvailable you use ReceiveFrom or ReceiveFrom6 which fills the same structure with the remote address, conveniently so you can reply. Angus

Your application should already be logging sufficient information to debug errors of this sort. If you are using the TSslHttpRest component, set debug level to DebugHdr. if not look at that component to see how it logs activities. Or try connecting to the proxy with the OverbyteIcsHttpRestTst sample. Angus

Sorry, you will need to diagnose the problem, I'm not guessing. Angus

That comment is ancient, written by another developer, not really looked at that code. Angus

The Delphi-MQTT project seems well written, but does not use TLS/SSL, easy to add that. I published a wish list here 18 months suggesting this could be added to ICS, the main issue is testing. This telemetry stuff really needs to be tested with non-Delphi applications and appliances, ideally in a real world environment, and I don't knowingly have any such things. Do have lots of Alexa capable devices on my LAN, no idea if they run MQTT. Angus

Are you aware of this ICS project: https://github.com/pjde/delphi-mqtt Angus

Would not recommend using httpAuthBasic unless you are setting credentials, there is usually a check for blanks, but that is a fail safe. Angus

Sorry, never looked at Squid. But ICS will not use TLS to a proxy irrespective of the port specified You really need some logging to see what is happening. Angus

That comment only relates to setting the various component proxy properties using a single URL, for convenience. The THttpCli component always connects to forward web proxies without HTTPS, but will make HTTPS requests through those proxies using the CONNECT method. Not sure if forward web proxies exist that use HTTPS. Angus

Thanks, just tidying up a few units, will be done today - not the SSL support... Angus

I offer zip and exe downloads of my application installers, Firefox is happy with both, Edge moans about the exe which is signed with a Sectigo certificate, but the Keep option allows it to be downloaded OK. Windows 10 itself allows exe files signed by Sectigo to be opened and run without any warning dialogs. I thought most Windows users were aware that Nanny Microsoft is overly cautious about download warnings and know how to ignore them. The only download problem I've had was when Google scanned some Delphi component downloads on my site and decided one was malicious, never told me which but possibly an OpenSSL DLL, that caused my domain to be blocked by all browsers including Firefox, only solution was to hide all such files with a password. Angus