Angus Robertson

The onClientMsg event is only triggered for published messages, Sorry, don't know off hand which event is triggered to acknowledge subscribe, you'll need to check the source code. Angus

My Mosquitto log shows exactly that. 2025-03-21T12:51:02: Received SUBSCRIBE from CID64860 2025-03-21T12:51:02: update/memo (QoS 2) 2025-03-21T12:51:02: Sending SUBACK to CID64860 Angus

First place to look would be the Mosquitto log file, maybe subscribe failed for some reason. I did test the latest version against local and remote Mosquitto servers, but my knowledge of the MQTT protocol is almost nil so I don't know what to expect when I click the various test buttons. Angus

ICS is simply reporting a REST API error that says your XML contains an error. So you need to correct your XML. Or maybe you are using the wrong API? Angus

https://www.iana.org/assignments/jose/jose.xhtml and https://www.iana.org/assignments/jwt/jwt.xhtml are a good start to JOSE and JWT and the RFCs that explain the standards for the numerous possible names. Angus

https://www.theregister.com/2025/04/14/ssl_tls_certificates/ https://www.feistyduck.com/newsletter/issue_124_certificate_lifetimes_to_shrink_to_just_forty_seven_days and numerous other sites that reported the same April vote, although https://cabforum.org/ has not yet been updated with the minutes of the meeting, or at least I can not find them. If you are interested in SSL/TLS, subscribe to the Feisty Duck monthly newsletter, it collects all the news. Angus

Currently, SSL/TLS certificates may be issued for a maximum period of 398 days, before renewal is required. The CA/Browser Forum recently voted to reduce this life span period in steps over the next four years. From 15th March 2026, life span is reduced to 200 days. From 15th March 2027, life span is reduced to 100 days. From 15th March 2029, life span is reduced to 47 days, but only 10 days for domain control validated certificates, such as most free certificates. These reduced life times reduce the effort needed to block compromised certificates, but also make manually updating server certificates more onerous. The Automatic Certificate Management Environment (ACME) developed by Let's Encrypt and used by many web servers, is now supported by other certificate vendors to issue free and commercial certificates automatically, and will hopefully be fully integrated with all major web servers by 2029. Let's Encrypt is adding a certificate profile to the ordering process, allowing alternate certificate types to be ordered, including six day life certificates later this year. It has also added a ACME command to get recommended renewal information, which is currently 30 days before a 90 day certificate expires. Applications are recommended to check renewal information regularly, currently every six hours, to check if certificates have been revoked. This will be important this summer when Let's Encrypt closes down the Online Certificate Status Protocol currently used to check if certificates are validly issued. A new version of the ICS TSslX509Certs component is currently being tested with these new ACME features, it will also attempt to support ordering certificates from Bypass, ZeroSSL, Google, DigiCert and ssl.com, although these most of these need accounts to be opened at the issuer before the ACME protocol can be used, so testing will not be quick and not all may be available initially. The main difference from Let's Encrypt is external accounting fields to link to the supplier's account, instead of just a public key. Minor changes to IcsHosts are needed for the ICS web server to handle certificate profiles and alternate suppliers, and to regularly update renewal information. These changes are already done in the OverbyteIcsX509CertsTst sample that is used to create ACME accounts and place certificate orders, that can be validated by an internal web server, external web servers such as Windows IIS and Windows Apache, and by Windows DNS server for wild card certificates. The sample supports multiple accounts for different suppliers, listing the status of all orders for those suppliers, and allowing ordering and renewals with a few clicks. I'll update this topic when the ICS web server is updated, hopefully within a week or two, meanwhile could anyone that has looked at alternate ACME suppliers let me know, to help with testing. Angus

For TCP and UDP client, setting LocalAddr attempts to bind to that address, if it exists. But it's generally a bad idea for clients to set LocalAddr, since IP addresses can be dynamic and change, interfaces can also come and go while your application is running. ICS has a component IcsIpChanges that reports such changes so servers in particular can know the IP address they are using has disappeared. BTW, please do not repeat everything I write, this is a threaded forum, so long quotes simply wastes space. Angus

In what way was my response unclear? Angus

For UDP server, TWSocket Addr and Port are set for listening. For UDP client, TWSocket LocalAddr and LocalPort may be set but are usually left blank, the remote address and port are specified in the SendTo method when sending data. Angus

After doing a couple of tests, it seems the SO_BSP_STATE API returns the local address allocated to the socket, usually 0.0.0.0, rather than the address chosen by Windows. We do get the random local port, so that could be used with the IpHlpConnsTable function to get a list of all connections on the PC, and search for the remote IP and local port, to find the local IP, major overhead to get a few bytes. Angus

I'm sure you are correct, but a few spare bytes in a buffer might provide future proofing. I'm surprised Socket_Address has not been used for other APIs, Microsoft has so many of these similar but not quite the same structures. Fortunately, ICS has a simple function to convert PSockAddrIn6 into a string. Angus

I've just got this working with new types Socket_Address = record { V9.5 used to store an IPv4 or IPv6 address } Sockaddr: PSockAddrIn6; SockaddrLength: Integer; end; TSocketAddress = Socket_Address; CSADDR_INFO = record { V9.5 used to connection IP information } LocalAddr: TSocketAddress; { family, address and port } RemoteAddr: TSocketAddress; iSocketType: Integer; { SOCK_STREAM or SOCK_DGRAM } iProtocol: Integer; { IPPROTO_TCP or IPPROTO_UDP } Buffer: array[0..64] of Byte; { space for PSockAddrIn6 records } end; TCSAddrInfo = CSADDR_INFO; Need to ensure it handles all ways of connecting, and update a sample to show the result, hopefully later today. Angus

Sorry, no time to debug this at the moment. Angus

You should wait until the socket is connected before trying to get socket connected information, use the OnSessionConnected event. Angus