Indy 10 TCPClient Keep Alive aktivieren

[QuickAndDirty]

Hallo,
Ich würde gerne für einen Indy 10 TIDTcpClient "keep alive" pakete aktivieren.
Irgendwie bekomme ich das nicht hin. Der Client läuft auf Android. Der Server hat "keep alive" nicht aktiviert.
Muss ich den Client mit nem bestimmten Compiler schalter kompilieren?

Delphi-Quellcode:

try
    If not TCPClient.Connected then
    Begin
      TCPClient.Host := fHost;
      TCPClient.Port := FPort;
      TCPClient.ConnectTimeout := FTimeout;
      TCPClient.ReadTimeout := FTimeout;
      TCPClient.Socket.Binding.SetKeepAliveValues(true,5000,1000);//Hier passiert der fehler
      TCPClient.Connect;
      Result := true;
      if Assigned(TCPClient.IOHandler) then
      Begin
        TCPClient.IOHandler.DefStringEncoding := IndyTextEncoding_ASCII;
        TCPClient.IOHandler.MaxLineLength := 1024*1024*10;
      End;
    end
    else
    Begin
      AlreadyConnected := 'Verbindung besteht bereits';
      result := true;
      exit;
    end
  except
    on E:Exception do
    Begin
      TCPClient.DisConnect;
      TCPClient.Free;
      TCPClient := nil;
      TCPClient := TIdTCPClient.Create(self);
      Result := false;
    end;
  end;

Folgender Fehler wird geworfen wenn in diesen code ausführe

Code:

Im Projekt TEST.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x011bb59a: read of address 0x000000e0' aufgetreten.

Ohne keep alive geht es.

Muss ich keep alive an beiden enden aktivieren oder versteht der INDY TCPserver , das der INdy tcpClient gerne keep alive pakete hätte?

Wenn ich das ganze nach dem Connect ausführe scheint es auch keine Fehler zu machen, allerdings erhofe ich mir eigentlich das das "connect" früher merkt das da nichts ist.
Aus irgendeinem Grund wird der ConnectTimeout nicht wirklich berücksichtigt , dachte ein keep alive könnte da helfen...

[mjustin]

Ein Beispiel ist hier zu finden: https://stackoverflow.com/questions/...wininet-client

Code:

procedure TForm1.IdHTTPServer1Connect(AContext: TIdContext);
begin
  // send a keep-alive every 1 second after
  // 5 seconds of inactivity has been detected
  AContext.Binding.SetKeepAliveValues(True, 5000, 1000);
end;

D.h. erst nach dem Connect kann die Methode aufgerufen werden.

Der ConnectTimeout wird bei Indy durch einen separaten Thread ausgelöst. Dauert es zu lange bis der Connect Timeout erscheint?

[QuickAndDirty]

@mJustin: Das ist kein http Server Client ding.
Alles pure TCP/IP
Und ich hatte mir ja den Befehl

TCPClient.Socket.Binding.SetKeepAliveValues(true,5 000,1000);

auch von da abgeguckt.
Ich verstehe leider die parameter
const ATimeMS, AInterval: Integer
dieser Funktion nicht....
also hab ich einfach mal 5000 und 1000 genommen.

[QuickAndDirty]

Zitat von mjustin:

Der ConnectTimeout wird bei Indy durch einen separaten Thread ausgelöst. Dauert es zu lange bis der Connect Timeout erscheint?

Dauert auf jedenfall länger als ne minute ...dann ist meine gedult am ende und ich schieße die app ab.
Der Connect timeout ist auf 5000 gestellt...der werd nicht wirklich berücksichtigt wie es scheint.

habe solche probleme nur bei seltsamen netzwerken...
Z.b.
Server steht in einem netz mit einem fallback LTE anschluss , über diesen läuft aber gefühlt jeder zweite Verbindungsaufbau...

[mjustin]

Zitat von QuickAndDirty:

@mJustin: Das ist kein http Server Client ding.

Das war auch nur ein konkretes Beispiel. Der Aufruf auf dem konkreten Binding erfolgt mit der gleichen Methode, unabhängig vom konkreten Protokoll.

Und 1 und 5 Sekunden sind wie im Beispiel sicher realistische Werte (d.h. 1000 und 5000 als Parameter, in Millisekunden)

[QuickAndDirty]

Vielleicht lasse ich es so einfach mal auf die Benuter los in der Hoffnung das er früher merkt , dass da nichts am anderen ende ist.

[mjustin]

Hier ist noch etwas zum Thema ConnectTimeout:

https://stackoverflow.com/questions/...t-does-not-ter

Zitat:

However, you have to take into account that ConnectTimeout only applies to the actual connection attempt (the call to the socket API connect() function). It does not apply to the time needed to resolve a hostname to an IP address, or to the time needed to create and tear down the worker thread that performs the actual connection while the timeout is monitored. So ConnectTimeout is not exact.

[QuickAndDirty]

Ich habe auch an anderer Stelle gelesen, dass dieser Verbindungaufbau ewig dauern kann wenn irgendetwas nicht "gracefull" beendet oder eingefroren wird...
sprich ich muss das aufbauen der Verbindung eigentlich in einem eigenen thread machen dessen Lebenszeit ich von außen messen und beenden kann damit ich knackige Verbindungszeiten habe oder eben dann direkt merke daß ich Offline weiter arbeiten muss.