TIDTCPIPClient.Connect ohne exception abbrechen

[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 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.

[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?

[jaenicke]

Zitat von QuickAndDirty:

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.

[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.