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 von QuickAndDirty:

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 von mjustin:

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 von 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); // <----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 von 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.

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.