TIDTCPIPClient.Connect ohne exception abbrechen

[QuickAndDirty]

So baue ich moment eine TCP Verbindung auf .

Delphi-Quellcode:

procedure TConnectCLientThread.Execute;
begin
  var attempts := 0;
  While (Not Terminated) and (Not Client.Connected) and (Attempts < MAX_CONNECTIONATTEMPTS) do
  Begin
    try
      inc(attempts);
      Client.Connect;
    Except
      On E:Exception do
      Begin
        TThreadedLog.LogD('TConnectCLientThread Connection attempt  number '+attempts.ToString+' : ' + E.Message);
      End;
    end;
  End;
end;

Ich würde das Verbinden gerne abbrechen können, daher diese Konstruktion.

Es wäre mir lieber wenn ich irgendwie and ohne Exception den ConnectionTimeout mitbekäme oder wenn ich z.b. einen infinite ConnectionTimeout setzten könnte und irgendwie den Connectionversuch ohne Exception abbrechen könnte.

Seht ihr da eine Chance?

[jaenicke]

Das wichtigste ist erst einmal, dass du von Indy zu ICS wechselst.

Indy nutzt immer blockierende Sockets, so dass du einen gestarteten Vorgang nicht abbrechen kannst. Timeouts kannst du natürlich nutzen, aber das ändert daran nichts, dass dann eben der entsprechende Thread hängt.

ICS nutzt aber nicht blockierende Sockets. Wenn du das Connect von TWSocket aufrufst, bekommst du ein Event OnSessionConnected, wenn die Verbindung hergestellt wurde. Das kannst du auch problemlos in einem Thread machen und wenn du die Verbindung oder den Verbindungsversuch abbrechen möchtest, rufst du einfach Close auf.

[QuickAndDirty]

Ich weiß nicht ob ich mal eben die Komponenten wechseln kann .
Es nervt einfach das der Programmfluss von Indy mit Exceptions geregelt wird, statt mit vernünftigen Rückgabe werten oder Events
Es gibt also keine Möglichkeit diese Exceptions zu vermeiden ? Jetzt so im Falle von Connect?

ICS hat keinen Android oder IOS Suppport ?

[mjustin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1546952)

So baue ich moment eine TCP Verbindung auf .
Ich würde das Verbinden gerne abbrechen können, daher diese Konstruktion.

In diesem Fall würde ich ein kleines ConnectTimeout setzen (z.B. 5 Sekunden), und dann Connect aufrufen bis die Verbindung erfolgreich war, oder die maximal Anzahl Verbindungsabbrüche erreicht ist. Defaultmäßig wartet Indy länger.

Exceptions haben hier den Vorteil, dass sie nicht so leicht übersehen können wie ein Rückgabewert und zudem auch noch Informationen zum Fehler liefern können. D.h. ob der Server überhaupt lokalisiert werden konnte ('No route to host') oder er die Verbindung verweigert hat ('Connection refused').

[jaenicke]

Es gibt verschiedene Timeouts, die eine Rolle spielen. Verbindung, lesen, schreiben, auf Socketebene, ... unter anderem:

Delphi-Quellcode:

uses
  IdStackConsts;

procedure SetClientTimeouts(AClient: TIdTCPClient);
begin
  AClient.ConnectTimeout := 5000;
  AClient.ReadTimeout := 5000;
  AClient.Socket.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_RCVTIMEO, 5000);
  AClient.Socket.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_SNDTIMEO, 5000);
end;

[DelTurbo]

Hi, kurz mal offtopic. Ich bin auch zu ICS gewechselt wenn es nur um Windows geht. Ansonsten halt Synapse wenn es Unix sein soll. Indy hat den nachteil das es mit altem OpenSSL abreitet.

HTTPS Clients sind schnell gemacht. Aber bei beiden bekomme ich den beim FTPClient den Datachanel nicht Protected.

[QuickAndDirty]

Zitat:

Zitat von mjustin (Beitrag 1546957)

In diesem Fall würde ich ein kleines ConnectTimeout setzen (z.B. 5 Sekunden), und dann Connect aufrufen bis die Verbindung erfolgreich war, oder die maximal Anzahl Verbindungsabbrüche erreicht ist. Defaultmäßig wartet Indy länger.

Ja genau so mache ich das ja.
Ich würde es nur gerne direkt abbrechen können ohne Exception oder Timeouten ohne Exception...ich mag dies art von controllflow nicht, einen Fehler zu werfen wo keiner ist.

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1546960)

Es gibt verschiedene Timeouts, die eine Rolle spielen. Verbindung, lesen, schreiben, auf Socketebene, ... unter anderem:

Delphi-Quellcode:

uses
  IdStackConsts;

procedure SetClientTimeouts(AClient: TIdTCPClient);
begin
  AClient.ConnectTimeout := 5000;
  AClient.ReadTimeout := 5000;
  AClient.Socket.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_RCVTIMEO, 5000); // <----Was machen diese beiden Zeilen?
  AClient.Socket.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_SNDTIMEO, 5000); // <----Was machen diese beiden Zeilen?
end;

Was machen die beiden Zeilen?

[QuickAndDirty]

Zitat:

Zitat von DelTurbo (Beitrag 1546982)

Hi, kurz mal offtopic. Ich bin auch zu ICS gewechselt wenn es nur um Windows geht. Ansonsten halt Synapse wenn es Unix sein soll. Indy hat den nachteil das es mit altem OpenSSL abreitet.

HTTPS Clients sind schnell gemacht. Aber bei beiden bekomme ich den beim FTPClient den Datachanel nicht Protected.

Es muss jetzt auf Windows, Android und IOs laufen und in absehbarer Zeit (scaleing) auf Linux.

Ich wünschte einfach nur Abbrechbarkeit und das Statusänderungen nicht durch Exceptions mitgeteilt werden.
:(

Ist ok wenn es nicht geht... dann weine ich einfach vor mich hin und lebe mit der Krücke und den EIDTimoutExceptions...die ich wohl aus dem Debugger ausbauen muss.

[DelTurbo]

Dann würde ich Synapse empfehlen. Und zwar von hier, das kann auch mir SSL 1.1 und 3.x umgehen.

[jaenicke]

Zitat:

Zitat von QuickAndDirty (Beitrag 1547005)

Was machen die beiden Zeilen?

Die setzen die Timeouts auf lowlevel Socketebene. Aber wenn das nicht nur unter Windows laufen soll, ist das der falsche Weg. Dann ist Indy aktuell ohnehin keine gute Idee, weil die veralteten OpenSSL Bibliotheken schon unter Windows ärgerlich sind, aber unter Android usw. noch schlechter sind.