These are chat archives for IndySockets/Indy
TIdCmdTCPClientare not intended to be used together (though they can, if you are careful with them), since they both run continuous reading threads, so it is easy to deadlock them. They are both receivers primarily. Typically, you should use
TIdTCPServer, depending on which side is initiating commands to the other. What does your protocol design look like? Not the specific details, just the flow of commands and responses?
TIdCmdTCPClientfor that. Simply run the
TIdTCPClientin a worker thread to avoid blocking your UI, and then have that thread notify the UI as needed when a response is received.
TIdCmdTCPClientand just send out your commands and move on, utilizing its existing reading thread to receive the responses, but only if the server's responses are formatted in such a way that the
CommandHandlerscan parse them.
TIdIRCworks this way, for instance. But it is not a typical useage.
TIdTCPCmdClientis generally meant for when a server sends commands to the client, and then the client responds.
TIdTCPClientin a worker thread (send a command, wait for response, repeat). If the latter, use
TIdCmdTCPClient(send a command, get notified when response arrives). I suppose either way will work
TIdHTTPServerand OpenSSL. But, using 5489 with OpenSSL 1.0.2q, I cannot reproduce that
EIdHTTPErrorParsingCommanderror, I am able to connect using both FireFox and Chrome (after having both accept a self-signed certificate I created for testing) and get the
OnCommandGetevent triggered and have it send a response back, using HTTPS.
EIdHTTPErrorParsingCommandmeans that the 1st line of a client's request is malformed (specifically, that it has no space characters in it to separate the request command from the HTTP version). Did you check to make sure that you are not acceidentally connecting to the HTTPS port using HTTP instead of HTTPS, or vice versa?