FearDC

I did not setup ICSHosts using INI, i did set them up using Object Inspector.

That's what I wanted to hear, that this is possible. This could be a great challenge for me, and a good solution for those many people asking for SSL and non-SSL on the same port. In fact whole this idea started from ICSHosts collection - your latest invention to multi-listening socket. I did specify a SSL and non-SSL port just to test this, but my server application doesn't listen on both ports, instead it listens on just a single SSL-enabled port 1412 - the non-SSL port 1411 is completely omitted. I could find this piece of code: This basically means that setting up both SSL and non-SSL, still different ports, using ICSHosts, is not possible. Is this a bug?

@Angus Robertson I'm not using a HTTP server, this is completely different type of protocol. Lets imagine that a SSL-enabled client connects to a SSL-enabled TSSLWSocketServer, he sends the client hello part of SSL handshake - in order to recognize/use this data we still need to read the bytes from client socket, right? Then once we have read these very first bytes, we actually check two first bytes - once they are magic (means SSL/TLS handshake) we keep shaking hands with the client as in SSL handshake, while if these bytes are not magic, we could just passthrough the SSL handshake and go directly to the TCP data exchange and keep this data exchange SSL-less all the way, as if SSLEnable was set to False for this particular client only. Do you understand what I mean? I'm not talking futuristic ideas right now, this has been implemented in a real software, which allows SSL-enabled and non-SSL clients to use same TCP port in same application > https://github.com/direct-connect/go-dcpp/blob/master/hub/hub.go#L506 . In this example, server application detects those magic bytes and configures the client socket to work either in SSL or non-SSL mode all the way. Ofcourse I understand that not all developers who work with TSSLWSocketServer would like this to be automated, because maybe the protocols they are working with, do actually send same type of magic bytes as part of the protocol. So this option should ofcourse be optional and disabled by default, so their projects don't get broken.