Entwickler-Ecke
Internet / Netzwerk - Port ueberpruefen - spezieller Fall
rockzOr - Fr 02.05.08 12:25
Titel: Port ueberpruefen - spezieller Fall
Hallo,
ich hab zwar schon einiges zu dem Thema gefunden, aber nichts, was in meinem Problem hilft.
Ich habe eine Funktion mit Hilfe von TCPClient geschrieben, die eine Verbindung zum Server oeffnet und nachprueft, ob der angegebene Port offen ist oder nicht.
Das funktioniert auch ohne Probleme, wenn der Server auf diesem Port hoert. Die nachfolgenden Dinge werden zuegig abgearbeitet und alles ist perfekt.
Jedoch wenn der Server (bzw. das Programm was darauf laeuft mit dem offenen Port) nicht online ist, dauert es 1 Minute, bis der TCPClient scheinbar ein Timeout meldet.
Nun zur Frage:
Gibt es eine Moeglichkeit diesen Timeout zu aendern oder anstelle des TCPClients eine andere Komponente zu verwenden, so dass der Timeout nicht so lange dauert (~10 Sekunden reichen da voellig)?
Waere ueber jeden Tip dankbar.
Der Code sieht momentan so aus (sehr vereinfacht, aber es tut wie gesagt bis auf das lange warten):
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
| tcpclient1.Active := true;
tcpclient1.Connect;
if tcpclient1.connected = true then
begin
end
else
begin
end;
tcpclient1.Disconnect; |
Gruss,
rockzOr
Narses - Fr 02.05.08 12:50
Titel: Re: Port ueberpruefen - spezieller Fall
Moin!
 rockzOr hat folgendes geschrieben: |
Jedoch wenn der Server (bzw. das Programm was darauf laeuft mit dem offenen Port) nicht online ist, dauert es 1 Minute, bis der TCPClient scheinbar ein Timeout meldet.
Nun zur Frage:
Gibt es eine Moeglichkeit diesen Timeout zu aendern |
Nein, das ist Design bei TCP.
cu
Narses
rockzOr - Fr 02.05.08 12:54
... und eine Alternative?
Kann auch ruhig was umstaendliches sein wie z.B. ein Timer der mitlaeuft und nach 10 Sekunden iwie einfach weiter macht oder so. Ich brauch einfach nur eine funktionale Idee/Tip dafuer ;)
Xentar - Fr 02.05.08 12:59
TIdTcpClient.Connect hat einen optionalen Parameter Timeout (Indy 9). Ich denke mal, den suchst du ;)
Narses - Fr 02.05.08 13:02
Moin!
| rockzOr hat folgendes geschrieben: |
| ... und eine Alternative? |
Ein TCP-Connect-Versuch (das, was du da Testen willst) verhält sich nun mal so, das ist Design der Socket-API (WSA, nicht Indy oder sonst eine Wrapper-Kompo). Wenn du die Verfügbarkeit eines TCP-Server-Ports mit einem Connect-Versuch testen willst, dann geht das nicht anders. :nixweiss:
| rockzOr hat folgendes geschrieben: |
| Kann auch ruhig was umstaendliches sein wie z.B. ein Timer der mitlaeuft und nach 10 Sekunden iwie einfach weiter macht oder so. Ich brauch einfach nur eine funktionale Idee/Tip dafuer ;) |
Da das "Problem" in der WSA liegt, gibt es zu dem Abwarten des Timeouts keine Alternative, egal welche Kompo du nimmst.
Du musst halt einen andern Weg, als einen TCP-Connect für den Verfügbarkeitstest wählen, um aus dem Timeout rauszukommen. :idea: Das hängt aber von dem Server und seinen/deinen Möglichkeiten für Verfügbarkeitstests ab...
cu
Narses
Xentar - Fr 02.05.08 13:06
Äh, achso, wir sind hier gar nicht bei den Indies.
OK, tschuldigung. Dachte, die wären inzwischen "Standard" ;)
Dann kannst du meinen Post ignorieren (oder als Anregung, auf die Indy Komponenten umzusteigen, auffassen)
rockzOr - Fr 02.05.08 13:07
Genial, genau das was ich gesucht hab. Danke! ;)
Jetzt hab ich nur noch das Problem, dass ich die Fehlermeldung(en) abfangen muss ^^ Wie mach ich das bei der Komponente?
/Edit: Hab das gerade mit dem IdTCPCLient ausprobiert und wie gesagt das ist genau das was ich brauche. Allerdings haengt mein Programm dann bei jeder Fehlermeldung die von der Komponente geworfen wird und das ist eher suboptimal ;)
Narses - Fr 02.05.08 13:10
Moin!
| rockzOr hat folgendes geschrieben: |
| Genial, genau das was ich gesucht hab. Danke! ;) |
Langsam, das Timeout runterzusetzen kann dir "falsche Ergebnisse" liefern. Das hat schon seinen Grund, warum das so, wie es gemacht wird, gemacht wird. :?
| rockzOr hat folgendes geschrieben: |
| Jetzt hab ich nur noch das Problem, dass ich die Fehlermeldung(en) abfangen muss ^^ Wie mach ich das bei der Komponente? |
Neue Frage, neuer Thread! ;)
cu
Narses
rockzOr - Fr 02.05.08 13:12
| Narses hat folgendes geschrieben: |
Moin!
| rockzOr hat folgendes geschrieben: | | Genial, genau das was ich gesucht hab. Danke! ;) |
Langsam, das Timeout runterzusetzen kann dir "falsche Ergebnisse" liefern. Das hat schon seinen Grund, warum das so, wie es gemacht wird, gemacht wird. :?
|
Inwiefern? Ich wuerde das Timeout auf 5 Sekunden setzen - ich weiss, dass der Server unter 5 Sekunden reagiert. Wenn nicht, dann ist er zu 100% nicht online. Das ist der Vorteil an meiner Situation ;)
Narses - Fr 02.05.08 13:17
Moin!
| rockzOr hat folgendes geschrieben: |
| Inwiefern? Ich wuerde das Timeout auf 5 Sekunden setzen - ich weiss, dass der Server unter 5 Sekunden reagiert. Wenn nicht, dann ist er zu 100% nicht online. |
Das einzige, was du nach den 5 Sekunden sicher weißt, ist, dass der Server nicht geantwortet hat - warum, das steht auf einem ganz anderen Blatt. :| Er könnte ausgelastet sein, die IP-Verbindung (gesamte Routingstrecke) könnte kurzzeitig unterbrochen sein (und dann später wieder laufen und das Paket trotzdem abliefern), etc.pp. Weiterhin ist der Timeout-Wert deshalb so "hoch", damit nicht alle Sekunde jemand einen TCP-Connect probiert (polling) und alleine damit den Server zuballert (mal auf mehr als dich alleine hochgerechnet)... Eine kleine Auswahl an Gründen. :idea: ;)
cu
Narses
rockzOr - Fr 02.05.08 13:22
Hehe das sind schon gute Gruende, allerdings kann ich das ueberschauen.
Das Programm was ich mache wird nur von maximal 100 Usern benutzt und das noch nichtmal gleichzeitig. Da eh nach Erfolg der Verbindungspruefung MySQL Querys abgeschickt werden, ist es ohnehin egal, wie lange der nun zum Antworten braucht. Sollte er eben nicht reagieren, wird einfach spaeter nochmal versucht. Wenn der Server ausgelastet ist, hat er ganz andere Probleme ^^ Und wenn mal die Routingstrecke nicht ordentlich funktioniert... Tja dann kann ich daran auch nichts aendern - das waere aber ebenso bei einem hohen Timeout. Und da nur maximal jede Minute ein neuer Request gesendet wird, kommts quasi aufs selbe raus ;)
Korrigier mich wenn ich total falsch liege.
Narses - Fr 02.05.08 13:27
Moin!
| rockzOr hat folgendes geschrieben: |
| Korrigier mich wenn ich total falsch liege. |
Mach doch deinen Connect-Versuch in einem Thread, wenn dich das Blockieren der GUI stört. :idea: ;)
Warum immer alle an öffentlich für gut befundenen Standards rumspielen müssen ("ich darf das, was andere Internetbenutzer tun, ist mir egal"), wird mir wohl ein Rätsel bleiben... :gruebel:
cu
Narses
rockzOr - Fr 02.05.08 13:35
Das wuerde aber dem Problem nicht zur Loesung beitragen. Micht stoert nicht das Blockieren der GUI, sondern das lange warten auf "Geht nicht" ;) Bzw mit persoenlich stoert das nicht, aber die "User" sind manchmal etwas ungeduldig und naja... dem Alter entsprechend leicht reizbar ;)
Ich halte mich normalerweise immer an Standards. In dem Falle muss bzw moechte ich aber eher dem Wunsch des Anwenders entsprechen, auch wenn dabei eben der Standard leidet.
Ich habe ja auch nicht gesagt, dass es mir egal ist, was andere tun. Deswegen ist der Threadname ja schon entsprechend "spezieller Fall" ;)
Narses - Fr 02.05.08 13:50
Moin!
Wenn dein Problem gelöst ist, markierst du den Thread dann noch entsprechend? Danke.
cu
Narses
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!