Delphi version : XE2,
Indy version: 10.5.8.0.
I have three procedures and all work fine until internet connection gets lost. When it will happen and after that I will try sending message then I can't reconnect when internet will be back. Can't close program (after on close program be not visible, but will use 100 cpu usage). Without "try, exception" there is a Socket Error #1053 on IdIRC1.Say and on Close. Thanks for help.
///Connection:
procedure TForm1.Button5Click(Sender : TObject);
begin
try
IdIRC1.Nickname := 'zzz';
IdIRC1.Password := 'kkk';
if IdIRC1.Connected then
IdIRC1.Disconnect;
IdIRC1.Connect;
IdIRC1.Join('#' + edit3.Text);
except
ShowMessage('ggg');
end;
end;
///Send message:
procedure TForm1.Button3Click(Sender : TObject);
begin
try
IdIRC1.Say('#' + edit3.Text, edit2.Text);
if (edit2.Text <> '') and (IdIRC1.Connected) then
begin
memo6.Lines.Add(edit2.Text);
Edit2.Clear;
end
else
ShowMessage('xxx');
except
ShowMessage('yyy');
end;
end;
///On close:
try
IdIRC1.Disconnect;
except
end;
When you encounter an error accessing the connection, such as because the connection was lost, you need to call Disconnect() and you need to clear the IOHandler.InputBuffer if it still has unread data in it. Disconnect() does not clear the InputBuffer, by design. If the InputBuffer is not empty, Connected() will return True even if the physical socket is disconnected.
Related
I use Delphi 10.1 Update 2 and Indy 10.6.2.5341.
We experience access violations in SSL_accept. This happens if a TIdTCPServer is setup using SSL and there is an open connection that has NOT yet negotiated TLS if the TIdTCPServer is stopped.
This looks like a problem in Libssl32 or Indy. This can be simply reproduced with the following code and Putty using a RAW connection. Does anyone knows a solution (or workaround) to prevent these crashes?
procedure TSslCrash.HandlerOnExecute(AContext: TIdContext);
begin
//
end;
procedure TSslCrash.HandlerOnConnect(AContext: TIdContext);
begin
TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough := False;
end;
procedure TSslCrash.ButtonStartClick(Sender: TObject);
begin
LServer := TIdTCPServer.Create;
LIOHandler := TIdServerIOHandlerSSLOpenSSL.Create;
LIOHandler.SSLOptions.Mode := sslmServer;
LIOHandler.SSLOptions.Method := sslvTLSv1_2;
LIOHandler.SSLOptions.VerifyMode := [];
LIOHandler.SSLOptions.VerifyDepth := 0;
LIOHandler.SSLOptions.CertFile := 'localhost.crt';
LIOHandler.SSLOptions.RootCertFile := 'localhost.crt';
LIOHandler.SSLOptions.KeyFile := 'localhost.key';
LServer.Bindings.Add.Port := 10000;
LServer.IOHandler := LIOHandler;
LServer.OnExecute := HandlerOnExecute;
LServer.OnConnect := HandlerOnConnect;
LServer.Active := True;
//Now open a RAW connection with Putty on port 10000 and keep it open
end;
procedure TSslCrash.ButtonStopClick(Sender: TObject);
begin
if Assigned(LServer) then begin
LServer.Active := False; //This causes an AV in TIdSSLSocket.Accept
FreeAndNil(LIOHandler);
FreeAndNil(LServer);
end;
end;
When Putty is connected in Raw mode, there is no SSL/TLS handshake performed, so SSL_accept() is stuck waiting for a handshake request that never arrives.
When TIdTCPServer is being deactivated, it disconnects active socket connections, failing any blocking socket operations in progress in other threads. In the case of SSL_accept(), that should unblock it so it can exit with an error code that TIdSSLSocket.Accept() can then detect and wrap into a raised exception (EIdOSSLUnderlyingCryptoError, EIdOSSLAcceptError, EIdSocketError, etc depending on the nature of the error code) in the context of the client thread that is waiting for the handshake to complete.
However, when TIdTCPServer is disconnecting a socket connection during deactivation, TIdTCPConnection.Disconnect() is called, which calls TIdIOHandler.Close(), which TIdSSLIOhandlerSocketOpenSSL has overridden to free its internal TIdSSLSocket object - the same object that is calling SSL_accept(). So it is quite likely that the underlying OpenSSL SSL object is being freed in TIdSSLSocket.Destroy() (which calls SSL_shutdown() and SSL_free()) in the context of the deactivating thread while still actively being used in TIdSSLObject.Accept() (which calls SSL_accept()) in the context of the client thread, thus causing an Access Violation.
There is not much that can be done about this without altering Indy's source code. For instance, maybe change TIdCustomTCPServer.DoTerminateContext() to call AContext.Binding.CloseSocket() instead of AContext.Connection.Disconnect(False) so the IOHandler itself is not closed, just the underlying socket (similar to what TIdCustomTCPServer.StopListening() does when terminating its listening accept() threads).
I have opened a ticket in Indy's issue tracker for you:
#218: Access Violation in SSL_accept() when deactivating TIdTCPServer
I'm using Delphi 10 Seattle to build a simple Client/Server application using the TIdTCPClientand TIdTCPServer components.
For read the data arrived from the server application (TIdTCPServer) I'm using a Thread in the Client Application.
This is the Execute method
procedure TClientReadThread.Execute;
begin
while not Terminated do
begin
try
if FClient.Connected() then //FClient is TIdTCPClient
begin
if not FClient.IOHandler.InputBufferIsEmpty then
begin
AResponse := FClient.IOHandler.ReadLn();
Synchronize(NotifyReadln);
end
else
FClient.IOHandler.CheckForDataOnSource(10);
end;
except
on E: Exception do
begin
// Send the exception message to the logger
FE:=E;
Synchronize(LogException);
end;
end;
end;
end;
Under normal circumstances all is working fine, but now I'm doing some tests to restore the connection on the client application in case which the server or the network is down. So I shutdown the server App to simulate a issue when the comm fails.
When that happens the client application detects which the server is gone using the TIdTCPClient.OnStatus event.
After that I try to terminate the reading thread using this code
if Assigned(FClientReadThr) then
begin
FClientReadThr.Terminate;
FClientReadThr.WaitFor; // This never returns.
FreeAndNil(FClientReadThr);
end;
But the WaitFor function never returns.
SO the question is , there is something wrong on my execute procedure which is preventing the finalization of the thread?
Exist a better way to terminate the thread?
First, you should not be using Connected() in this manner. Just call ReadLn() unconditionally and let it raise an exception if an error/disconnect occurs:
procedure TClientReadThread.Execute;
begin
while not Terminated do
begin
try
AResponse := FClient.IOHandler.ReadLn();
Synchronize(NotifyReadln);
except
// ...
end;
end;
end;
If you want to poll the socket for data manually, it should look more like this:
procedure TClientReadThread.Execute;
begin
while not Terminated do
begin
try
if FClient.IOHandler.InputBufferIsEmpty then
begin
FClient.IOHandler.CheckForDataOnSource(10);
FClient.IOHandler.CheckForDisconnect;
if FClient.IOHandler.InputBufferIsEmpty then Continue;
end;
AResponse := FClient.IOHandler.ReadLn();
Synchronize(NotifyReadln);
except
// ...
end;
end;
end;
DO NOT use the TIdTCPClient.OnStatus event to detect a disconnect in this situation. You are deadlocking your code if you are terminating the thread directly in the OnStatus event handler. That event will be called in the context of the thread, since the thread is the one reading the connection and detecting the disconnect. So your thread ends up waiting on itself, that is why WaitFor() does not exit.
I would suggest an alternative approach. DON'T terminate the thread at all. To recover the connection, add another level of looping to the thread and let it detect the disconnect and reconnect automatically:
procedure TClientReadThread.Execute;
var
I: Integer;
begin
while not Terminated do
begin
try
// don't call Connect() in the main thread anymore, do it here instead
FClient.Connect;
except
// Send the exception message to the logger
// you should wait a few seconds before attempting to reconnect,
// don't flood the network with connection requests...
for I := 1 to 5 do
begin
if Terminated then Exit;
Sleep(1000);
end;
Continue;
end;
try
try
while not Terminated do
begin
AResponse := FClient.IOHandler.ReadLn();
Synchronize(NotifyReadln);
end;
except
// Send the exception message to the logger
end;
finally
FClient.Disconnect;
end;
end;
end;
You can then Terminate() and WaitFor() the thread normally when you want to stop using your socket I/O.
I want to establish a communication between TIdTCPServer and TIdTCPClient in delphi and this is how my procedures look :
1.Server side :
procedure TMainForm.IdTCPServer1Execute(AContext: TIdContext);
var
clientReq, clientName : String;
begin
clientReq := AContext.Connection.IOHandler.ReadLn(); // client sends request
clientName := extractClientName(clientReq);
AContext.Connection.IOHandler.WriteLn('Hello ' + clientName);
end;
2.Client side :
procedure TMainForm.btnTestClientClick(Sender: TObject);
var
testTCP : TIdTCPClient;
clientReq, serverResponse : String;
begin
testTCP := TIdTCPClient.Create;
try
testTCP.Host := wantedHost;
testTCP.Port := wantedPort;
testTCP.Connect;
clientReq := 'Hello, my Name is user1.';
testTCP.IOHandler.WriteLn(clientReq);
try
serverResponse := testTCP.IOHandler.ReadLn();
except on e : Exception do begin
ShowMessage('Error reading response =' + e.Message);
end;
end;
finally
FreeAndNil(testTCP);
end;
end;
I connect to the server but than my application freezes when I try to receive the response from the server OnExecute event with my TCPClient.IOHandler.ReadLn method. Can anyone help me fix my code or show me a working example of what I'm trying to do (with Indy's TIdTCPClient and TIdTCPServer) ?
There is nothing wrong with the code you have shown, so the problem has to be in the code you have not shown. The way I see it, there are two possibilities:
If you are not setting wantedHost and/or wantedPort to the correct values, you would not actually be connecting to your expected server.
If extractClientName() is getting stuck internally and not exiting, the server would not be sending any response. One way that could happen is if you are running the client and server in the same process, and extractClientName() syncs with the main thread, but the main thread is blocked waiting on the client and cannot process the sync, so a deadlock occurs.
Good morning to all.I am building a Delphi TCP server/client application using Indy 10.0.52,with TIdTCPClient and TIdTCPServer. I have problem with receiving asynchronous responses from server. Here's my part of sample code:
Client:
procedure TfrmMain.ClientSend();
begin
tcpClient.IOHandler.WriteLn('100|HelloServer');
if tcpClient.IOHandler.ReadLn() = '1100' then //Here I get 1100
begin
tcpClient.IOHandler.WriteLn('200|Are_you_ready_for_data?');
if tcpClient.IOHandler.ReadLn() = '1200' then
begin
end;
end;
end;
Server:
procedure TfrmMain.tcpServerExecute(AContext: TIdContext);
var command:Integer;
var received,value:String;
begin
received := AContext.Connection.IOHandler.ReadLn;
command := StrToInt(SomeSplitFunction(received,'first_part')); //Here I get 100
value := SomeSplitFunction(received,'second_part'); //Here I get 'HelloServer'
case command of
100:begin
//Do something with value...
AContext.Connection.IOHandler.WriteLn('1100');
end;
200:begin
//Do something with value...
AContext.Connection.IOHandler.WriteLn('1200');
end;
end;
end;
The problem is that the case 200 on tcpServerExecute is never executed, therefore the second ReadLn on client site is never read.Is multiple asynchronous data sending in single procedure supported?I have came across several examples with simple Indy TCP Server/Client applications, but I'm little stuck here.Just to mention that connection is working and I connect to server without problems.
I am having problem with IdTCPclient.connected function from Indy in Delphi. I am using Indy10 and Delphi2010 environment. My problem is every time i check the TCP connection with IdTCPclient.connected, it raises exception with these errors EidSocketError, EidReadTimeOut. Is there any way to disconnect and reconnect the connection? (like reset the connection).
Note: I set TCPClient.ReTimeout:= 30000;
The implemented coding for reset the connection is follow.
if IdTCPclient.connected then
begin
IdTCPclient.IOHandler.InputBuffer.Clear;
IdTCPclient.Disconnect;
end;
sleep(1000);
try
IdTCPclient.connect;
except
on E: Exception do
MessageDlg('Connecting Error: '+E.Message, mtError, [mbOk], 0);
end;
But some point, i get exception and it couldn't connect at all. I am not sure what i am doing wrong.
Should i do this?
Disconnect first
Clear input buffer
Destroy TCPclient
Re-create new TCPclient
And then connect it again
If it is the case, can someone provide me a way how to do it properly?
Also, there is another function to re-connecting the TCP in my coding. It also gives me exception as well. I check the connecting before i send a message to TCP. If there is no connection, i reconnect for five times.
result := IdTCPclient.connected
if not result then
begin
for k:=0 to 4 do
beign
sleep(1000);
try
TCPclient.connect;
except
on E: Exception do
MessageDlg('Connecting Error: '+E.Message, mtError, [mbOk], 0);
end
result := TCPclient.connected;
if result then break;
end;
With above two coding, program handles reconnecting and reset the connection pretty well. But some point the program cannot re-connect or reset the connection at all.
What should i do when i get exception? Should i reconnect from exception?
How do we build coding to check the connection regularly?
How do we build coding to to get back the connection when it lost?
Kind regards,
Connected() should not be raising any exceptions at all. If it is, then it is likely a bug. Please provide a stack trace showing that.
The best option is to simply avoid using Connected() whenever possible. When you need to perform an I/O operation, just do so, and let Indy raise an exception if a failure occurs. You can then handle it at that moment, eg:
try
IdTCPClient.DoSomething...
except
on E: EIdException do begin
Reconnect;
end;
end;
procedure Reconnect;
var
k: Integer;
begin
IdTCPClient.Disconnect;
if IdTCPClient.IOHandler <> nil then
IdTCPClient.IOHandler.InputBuffer.Clear;
for k := 0 to 4 do
begin
Sleep(1000);
try
IdTCPClient.Connect;
Exit;
except
on E: Exception do
begin
MessageDlg('Connecting Error: '+E.Message, mtError, [mbOk], 0);
if k = 4 then
raise;
end;
end;
end;
end;
before you connect make sure that the passive Boolean of idftp is false
when you need file transfert change it to true with binary file option