These are chat archives for IndySockets/Indy

10th
Dec 2018
DelphiWorlds
@DelphiWorlds
Dec 10 2018 12:02
I have the following scenario: Using a TIdCmdTCPServer in a server app, and a corresponding TIdCmdTCPClient in the client. At least one of the commands can result in a (possibly) long-running process that eventually returns a result. What might be the best way for the client to handle this, given that I’d rather not "tie up" the client process while it is waiting for the result?
Remy Lebeau
@rlebeau
Dec 10 2018 18:18
@DelphiWorlds TIdCmdTCPServer and TIdCmdTCPClient are 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 TIdTCPClient with TIdCmdTCPServer, and TIdCmdTCPClient with 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?
DelphiWorlds
@DelphiWorlds
Dec 10 2018 18:58
I meant that the TIdCmdTCPClient is in a separate app, i.e. a client
Remy Lebeau
@rlebeau
Dec 10 2018 19:00
@DelphiWorlds I understand that, but my point is that since both components are primarily receivers, you can end up in a situation where client and server are both trying to read only and not send anything to each other, deadlocking communications. That is why I ask what your command/response flow actually looks like.
DelphiWorlds
@DelphiWorlds
Dec 10 2018 19:19
the client initiates a command with the server.. the server executes it, and as I say, some commands may take some time to complete.. then the server sends the response back to the client
Remy Lebeau
@rlebeau
Dec 10 2018 19:24
@DelphiWorlds I would not use TIdCmdTCPClient for that. Simply run the TIdTCPClient in a worker thread to avoid blocking your UI, and then have that thread notify the UI as needed when a response is received.
DelphiWorlds
@DelphiWorlds
Dec 10 2018 19:24
OK.. thanks!
Remy Lebeau
@rlebeau
Dec 10 2018 19:27
@DelphiWorlds I mean, it is possible to use TIdCmdTCPClient and 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 CommandHandlers can parse them. TIdIRC works this way, for instance. But it is not a typical useage. TIdTCPCmdClient is generally meant for when a server sends commands to the client, and then the client responds.
DelphiWorlds
@DelphiWorlds
Dec 10 2018 19:30
"only if the server's responses are formatted in such a way that the CommandHandlers can parse them"
well, that’s the intent
Remy Lebeau
@rlebeau
Dec 10 2018 19:36
@DelphiWorlds It comes down to whether you want your client to handle communications synchronously or asynchronously. If the former, use TIdTCPClient in 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
DelphiWorlds
@DelphiWorlds
Dec 10 2018 20:54
@rlebeau Thanks for your help
John
@JEisenheim_twitter
Dec 10 2018 22:43
Hi, Indy 10 5489, TidHTTPServer raises EIdHTTPErrorParsingCommand when client (Chrome, FF) connects with SSL. Now I jump back to Indy 5451 which is working correctly. Just wondering if something SSL related was changed in the latest snapshots??? Using OpenSSL 1.0.2q.
Remy Lebeau
@rlebeau
Dec 10 2018 23:51
@JEisenheim_twitter there have been a number of edits to Indy between 5451 and 5489, several of which are related to TIdHTTPServer and OpenSSL. But, using 5489 with OpenSSL 1.0.2q, I cannot reproduce that EIdHTTPErrorParsingCommand error, 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 OnCommandGet event triggered and have it send a response back, using HTTPS. EIdHTTPErrorParsingCommand means 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?