IndySecOpenSSL is now available on OPM

[TheMouseAUS]

All looking good, im down to one issue left that I am struggling with.

The clients connect to server and all is well. The read/write are in try blocks so if there is a connection issue ( bad wifi etc) they will disconnect and then try to reconnect. This works great if I am not using ssl with the client IOHandler set to IndySecOpenSSL but if SSL is enabled then the application just freezes until sometime after the connection comes a live again.

This is not great, I have tried setting IdSecIOHandlerSocketOpenSSL1.ReadTimeout and IdSecIOHandlerSocketOpenSSL1.ConnectTimeout but nothing seems to influence this.
I also tried IdSecIOHandlerSocketOpenSSL1.CheckForDisconnect but that seemed not to do much either.

At the moment it seems to only way around this is to Connect -> request Data -> get response -> disconnect, this seems very clunky though and there has to be a better way.

Once again I have turned to examples as documentation seems very hard to find,  not much seems to be pointing me in the right direction. Can someone please help? Thanks

[LeP]

I think you must set the IdTCPClient1.Socket.ConnectTimeout ... ReadTimeout and SendTimeout ONLY after you assigned IOHandler to TCP.

In this way the socket should be really set. Take care that if you set 0, the timeout became the OS default value. Set a value of some ms. like 100.

[TheMouseAUS]

Thanks for your reply :-), I already am setting timeouts after IOHandler is assigned but they do not seem to work.

[LeP]

Thanks for your reply :-), I already am setting timeouts after IOHandler is assigned but they do not seem to work.

I tried too, and confirm that set the timeout (I tried ConnectTimeout) value doesn't change anything. Seems that Timeout used is locked to something else.

Tomorrw I will investigate about this.

[TheMouseAUS]

I thought I would try with TaurusTLS as TCPClient IOHandler and it seems to works as expected.

[TheMouseAUS]

Something else i found today.

If the client has timed out and dropped the socket and IndySecOpenSSL is used for the IOHandler, the try statement does not capture the exception of the dropped the socket

Code: Pascal  [Select][+][-]

1. procedure IdTCPServer1Execute(AContext: TIdContext);
2. begin
3. With AContext.Connection.IOHandler do
4.   try
5.     Write(ms, ms.size, true);
6.   except
7.     on E : Exception do
8.     // do stuff
9.   end;
10. end;
11.  

I had to add this otherwise I get GPF.

Code: Pascal  [Select][+][-]

1. procedure IdTCPServer1Execute(AContext: TIdContext);
2. begin
3. With AContext.Connection.IOHandler do
4.   try
5.     if AContext.Connection.Connected then Write(ms, ms.size, true);
6.   except
7.     on E : Exception do
8.     // do stuff
9.   end;
10. end;
11.  

[LeP]

You will always in the bad lands ... I mean: you test the connection and 1 nanosecond after the connection is lost ... and your software will crash ?

Every time something has to do with async events the software cannot crash. The event should be signaled, but should be managed.

I don't remember something similar, shoul be generate an exception. May be in the IOHandler something is not managed ?

Are you working with TaurusTLS or IndySecOpenSSL ?

[TheMouseAUS]

The client had requested a function, that took the server just over 1 sec to complete, this exceeded the clients time out and crashed the server. I took me ages to work out that was issue. I was thinking I had got my TCriticalSections wrong. Once I finally realized it was the client disconnect causing the issue I fixed it as below. I was just surprised that the write exception was not captured.

Im using IndySecOpenSSL.

Also some of the clients are on wifi, if the signal drops after they have send a request then the reply socket will be gone. Hopefully this small fix with sort that out. I cant have a client disconnect crash a server like it was.