Laestiger Timeout beim Zugriff auf nicht (mehr) verfuegbare Netzwerkfreigaben
Michael Landenberger
es gibt bekanntlich viele Programme, mit denen man u. a. Dateien und Ordner
auf anderen Rechnern im Netzwerk zugreifen kann. Manche dieser Programme
speichern auch den zuletzt benutzten Pfad, um dann z. B. einen "Datei
öffnen"-Dialog später wieder mit eben diesem Pfad zu initialisieren.
Nun kann es aber vorkommen, dass die zuletzt geöffnete Netzwerkfreigabe
nicht mehr zur Verfügung steht, z. B. weil der Host mittlerweile offline
ist. Leider dauert es aber sehr lang, bis Windows das mitbekommt. Manche
Programme (darunter sogar der Windows Explorer, aber auch Firefox u. a.)
frieren während des Zugriffsversuchs ein und sind nur noch eingeschränkt
oder gar nicht mehr benutzbar. Wenn der Zugriff automatisch erfolgt, kann
der Benutzer den vergeblichen Zugriff nicht verhindern, d. h. es bleibt ihm
nichts anderes übrig als zu warten, bis Windows endlich gemerkt hat, dass
eine Netzwerkressource nicht mehr verfügbar ist. Das kann manchmal bis zu
einer Minute dauern und ist ausgesprochen lästig.
Nun bin ich gerade dabei, ein eigenes Programm zu schreiben, welches
ebenfalls auf Netzwerkfreigaben zugreift. Allerdings soll dieses Programm
schneller reagieren, wenn eine Ressource nicht (mehr) verfügbar ist. Ich
habe festgestellt, dass das mit den Standard-Routinen, die das Windows API
für den Dateizugriff über UNC-Pfade bereitstellt, nicht realisierbar ist
(falls jemand einen Tipp hat, wie es doch geht, wäre ich dankbar). Ich bin
daher auf die Idee gekommen, den betreffenden Host vor dem eigentlichen
Dateizugriff erst einmal anzupingen. Wenn der Host auf Pings nicht reagiert,
betrachte ich ihn als offline und versuche gar nicht erst, darauf
zuzugreifen.
Mein Programm schickt also vor jedem Dateizugriff auf UNC-Pfade á la
\\host\ordner\datei zunächst einen ICMP-Ping an den Host. Das
Zeitaufwendigste dabei ist die Namensauflösung. Kann der Hostname nicht
aufgelöst werden, liefert die Namensauflösung schon nach wenigen Sekunden
eine entsprechende Rückmeldung. Diese nimmt mein Programm zum Anlass, jeden
weiteren Zugriffsversuch zu unterlassen, womit vermieden wird, dass es durch
den ewig langen Timeout bei Dateizugriffen blockiert wird. Klappt die
Namensauflösung jedoch, wird als nächstes ein ICMP-Ping an die ermittelte IP
geschickt. Wenn der Ping ins Leere läuft, wird das ebenfalls als Indiz für
einen nicht erreichbaren Host gewertet. Nur wenn der Host auf den Ping
antwortet, wird tatsächlich auf die Netzwerkressource zugegriffen.
Für den Ping habe ich derzeit einen Timeout von 100 ms eingestellt, was für
LAN-Zugriffe vollkommen ausreichen sollte. Die ganze Prüfung incl.
Namensauflösung und Ping dauert also maximal einige Sekunden. Danach weiß
mein Programm, ob eine Netzwerkressource verfügbar ist oder nicht, und
verhält sich entsprechend. Im Gegensatz dazu dauert es bei einem regulären
Dateizugriff manchmal bis zu einer Minute, bis Windows mitbekommt, dass der
Host offline ist. In dieser Zeit "hängt" nicht nur mein Programm, sondern
jedes Programm, das Standard-API-Funktionen für Dateizugriffe im Netzwerk
verwendet.
Lange Rede, kurzer Sinn: die Sache funktioniert bisher perfekt. Nun würde
ich gerne von den Netzwerkexperten wissen, ob irgend etwas gegen diese
Vorgehensweise spricht. Es geht *ausschließlich* um LAN-Zugriffe, und ich
kann ausschließen, dass ICMP Ping Requests geblockt werden.
Beteiligte Betriebssysteme: Windows XP, Vista, Windows 7.
Gruß
Michael
Heiko Nocon
>Leider dauert es aber sehr lang, bis Windows das mitbekommt.
Man kann diesen Timeout beliebig beinflussen.
>Manche
>Programme (darunter sogar der Windows Explorer, aber auch Firefox u. a.)
>frieren während des Zugriffsversuchs ein und sind nur noch eingeschränkt
>oder gar nicht mehr benutzbar.
Tja, gegen dumme Programmierer ist leider kein Kraut gewachsen. Wenn man
potentiell langdauernde Operationen im Haupthread behandelt, kann der
nicht gleichzeitig das GUI behandeln, wenn sie mal wirklich lange
dauern.
>Nun bin ich gerade dabei, ein eigenes Programm zu schreiben, welches
>ebenfalls auf Netzwerkfreigaben zugreift. Allerdings soll dieses Programm
>schneller reagieren, wenn eine Ressource nicht (mehr) verfügbar ist. Ich
>habe festgestellt, dass das mit den Standard-Routinen, die das Windows API
>für den Dateizugriff über UNC-Pfade bereitstellt, nicht realisierbar ist
>(falls jemand einen Tipp hat, wie es doch geht, wäre ich dankbar).
Die Einstellung ist global. Man kann aber auch ohne Änderung dieser
Einstellung Programme schreiben, die nicht "hängen", wenn der Zugriff
mal länger dauert oder nach dem Standard-Timeout ganz scheitert. Einfach
indem man das GUI von der Netzwerkgeschichte entkoppelt, indem man
getrennte Threads dafür verwendet.
>Ich bin
>daher auf die Idee gekommen, den betreffenden Host vor dem eigentlichen
>Dateizugriff erst einmal anzupingen.
Schwachsinnige Idee, die nur an Symptomen rumdoktort. Beispiel: Ping
super, aber SMB unmöglich, weil halt der Paketfilter des Servers ICMP
Echo zuläßt, aber keine SMB-Kommunikation. Oder: Ping klappt gerade
noch, aber in diesem Moment wird der Server gerade runtergefahren. Die
Zahl möglicher Gegen-Szenarios läßt sich beliebig fortsetzen...
Michael Landenberger
> Die Einstellung ist global. Man kann aber auch ohne Änderung
> dieser Einstellung Programme schreiben, die nicht "hängen",
> wenn der Zugriff mal länger dauert oder nach dem Standard-Timeout
> ganz scheitert. Einfach indem man das GUI von der Netzwerkgeschichte
> entkoppelt, indem man getrennte Threads dafür verwendet.
Natürlich arbeitet mein Programm mit einem separaten Thread für
Netzwerkzugriffe. Allerdings stellt auch das keine befriedigende Lösung dar.
Der Subthread verhindert zwar, dass das Programm während des Zugriffs auf
eine Netzwerkressource blockiert wird, aber er verhindert leider nicht, dass
das Programm bis zu einer Minute lang nicht weiß, was Sache ist, und daher
auch nicht wirklich weiterkommt. Auch das wird der Benutzer nicht sonderlich
schön finden. Davon abgesehen hat der Timeout durchaus einen Sinn. Hier gibt
es z. B. einen Server, auf den recht selten zugegriffen wird. Dieser Server
legt seine Festplatten nach 30 Minuten Idle schlafen. Erfolgt dann ein
Zugriff, müssen die Festplatten erst wieder hochfahren. Das dauert ein
Weilchen, weswegen es durchaus sinnvoll ist, dass das Programm erstmal einen
Moment wartet und die Ressource nicht gleich als unerreichbar einstuft. Das
ist auch ein Grund, den Timeout nicht zu verändern (zumal mein Programm an
globalen Einstellungen sowieso nicht herumspielen soll).
Übrigens scheinen die von dir genannten "dummen Programmierer" u. a. auch
bei Microsoft zu sitzen. Beispiel: die durch die Windows API-Funktionen
GetOpenFileName bzw. GetSaveFileName bereitgestellten Dialoge merken sich
das zuletzt genutzte Verzeichnis in der Registry. Beim erneuten Aufruf eines
dieser Dialoge wird versucht, in das zuletzt geöffnete Verzeichnis zu
wechseln. Befindet sich dieses jedoch auf einem Host, der mittlerweile
offline ist, dann kommt es zu besagtem nervigem Timeout. Es dauert also bis
zu einer Minute, bis der Dialog überhaupt erscheint, und der Benutzer weiß
in dieser Zeit überhaupt nicht, was Sache ist. Er kann das Verhalten auch
nicht beeinflussen, d. h. selbst wenn er weiß, dass der Host offline ist,
kann er erst dann in ein anderes Verzeichnis wechseln, nachdem Windows seine
vergeblichen Zugriffsversuche auf den unerreichbaren Host beendet und den
Dialog endlich auf den Bildschirm gebracht hat. Absolut schwachsinnig, diese
Lösung. Ähnliches gilt für den Windows Explorer: klickt man da in der
Netzwerkumgebung auf eine unerreichbare Ressource, friert das
Explorer-Fenster erst einmal für eine Weile ein. Es ist mir ein Rätsel,
warum, denn die Erreichbarkeit eines Hosts kann man wesentlich schneller
prüfen.
> Schwachsinnige Idee, die nur an Symptomen rumdoktort. Beispiel:
> Ping super, aber SMB unmöglich, weil halt der Paketfilter des
> Servers ICMP Echo zuläßt, aber keine SMB-Kommunikation.
Auf "Server", die kein SMB zulassen, wird gar nicht zugegriffen, denn bei
denen gibt es sowieso nichts zu holen. Diese Situation ist also irrelevant.
Ich werde allerdings mal versuchen, anstatt eines Pings die Erreichbarkeit
der Port 139 und 445 beim Host zu prüfen (in der Hoffnung, dass diese
Prüfung ähnlich wie Ping ohne ewig langen Timeout funktioniert). Wenn diese
beiden Ports erreichbar sind, kann man ziemlich sicher davon ausgehen, dass
der Server läuft und SMB zugelassen ist.
> Oder: Ping klappt gerade noch, aber in diesem Moment wird der
> Server gerade runtergefahren.
Das dürfte so selten auftreten, dass man damit leben kann. Immerhin folgt ja
nach dem Ping ein regulärer Zugriffsversuch, der dann eben in den Timeout
läuft. Das ist zwar lästig, aber es kommt wie gesagt selten vor und Schaden
entsteht auch keiner.
Gruß
Michael
Ralph A. Schmid, dk5ras
>Ich werde allerdings mal versuchen, anstatt eines Pings die Erreichbarkeit
>der Port 139 und 445 beim Host zu prüfen (in der Hoffnung, dass diese
>Prüfung ähnlich wie Ping ohne ewig langen Timeout funktioniert). Wenn diese
>beiden Ports erreichbar sind, kann man ziemlich sicher davon ausgehen, dass
>der Server läuft und SMB zugelassen ist.
Falls im Szenario auch mal VPNs vorkommen können, denke an die
Latenzen, die eine Mobilfunkverbindung erzeugt. Wenn eh alles immer
lokal eng beisammen steht, dann sollte das dagegen irrelevant sein.
-ras
--
Ralph A. Schmid
http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Michael Landenberger
> Falls im Szenario auch mal VPNs vorkommen können, denke an die
> Latenzen, die eine Mobilfunkverbindung erzeugt. Wenn eh alles
> immer lokal eng beisammen steht, dann sollte das dagegen
> irrelevant sein.
Ich habe jetzt die Ping-Prüfung durch eine Prüfung auf offene Ports 139 oder
445 ersetzt. Das läuft zumindest im LAN ebenfalls ohne nennenswerte
Verzögerung und dürfte auch Latenzen berücksichtigen. Ein Timeout wird bei
der Port-Prüfung nicht vorgegeben, d. h. die Prüfung wartet, bis die
Verbindung zum Remote-Host hergestellt wurde. Das dauert aber im LAN nur
wenige Millisekunden. Das ist nichts im Vergleich zu der Wartezeit, die man
in Kauf nehmen muss, wenn man ohne vorherige Prüfung auf eine nicht
verfügbare Netzwerkressource zugreift.
Gruß
Michael
Thomas Proppe
> Michael Landenberger wrote:
>
>> Leider dauert es aber sehr lang, bis Windows das mitbekommt.
>
> Man kann diesen Timeout beliebig beinflussen.
>
Hallo Heiko,
hättest Du einen Tipp, an welcher Stelle man das bei Windwows (XP/7)
einstellen kann? Hier gibt es auch ein paar Kandidaten an Programmen,
die immer auf den zuletzt bekannten Pfad zugreifen wollen. Wenn der
nicht da ist, ist erst mal warten angesagt.
Oder bezog sich das beliebig beeinflussen auf die Programmierung?
Thomas
Christoph
> Am 13.03.2011 03:02, schrieb Heiko Nocon:
>> Michael Landenberger wrote:
>>
>>> Leider dauert es aber sehr lang, bis Windows das mitbekommt.
>>
>> Man kann diesen Timeout beliebig beinflussen.
>>
>
> Hallo Heiko,
>
> hättest Du einen Tipp, an welcher Stelle man das bei Windwows
für XP probiere mal: Ordneroptionen, Ansicht, [ ] "Automatisch
nach Netzwerkordnern ..." (zweiter Kasten von oben). Ist es das,
was du suchst?
Christoph
--
email:
nurfuerspam -> gmx
de -> net
Arno Welzel
> "Heiko Nocon" <Heiko...@gmx.net> schrieb:
>
>> Die Einstellung ist global. Man kann aber auch ohne Änderung
>> dieser Einstellung Programme schreiben, die nicht "hängen",
>> wenn der Zugriff mal länger dauert oder nach dem Standard-Timeout
>> ganz scheitert. Einfach indem man das GUI von der Netzwerkgeschichte
>> entkoppelt, indem man getrennte Threads dafür verwendet.
>
> Natürlich arbeitet mein Programm mit einem separaten Thread für
> Netzwerkzugriffe. Allerdings stellt auch das keine befriedigende Lösung dar.
> Der Subthread verhindert zwar, dass das Programm während des Zugriffs auf
> eine Netzwerkressource blockiert wird, aber er verhindert leider nicht, dass
> das Programm bis zu einer Minute lang nicht weiß, was Sache ist, und daher
> auch nicht wirklich weiterkommt. Auch das wird der Benutzer nicht sonderlich
Was eben nicht anders geht, wenn der Zugriffsversuch eine benötigte aber
nicht verfügbare Ressource potentiell bis zu einer Minute lang keine
Antwort liefert.
[...]
>> Schwachsinnige Idee, die nur an Symptomen rumdoktort. Beispiel:
>> Ping super, aber SMB unmöglich, weil halt der Paketfilter des
>> Servers ICMP Echo zuläßt, aber keine SMB-Kommunikation.
>
> Auf "Server", die kein SMB zulassen, wird gar nicht zugegriffen, denn bei
> denen gibt es sowieso nichts zu holen. Diese Situation ist also irrelevant.
>
> Ich werde allerdings mal versuchen, anstatt eines Pings die Erreichbarkeit
> der Port 139 und 445 beim Host zu prüfen (in der Hoffnung, dass diese
> Prüfung ähnlich wie Ping ohne ewig langen Timeout funktioniert). Wenn diese
> beiden Ports erreichbar sind, kann man ziemlich sicher davon ausgehen, dass
> der Server läuft und SMB zugelassen ist.
Damit vermischt Du aber heftig völlig verschiedene Ebenen - und musst
abhängig vom Dateinamen mehr oder weniger "raten", ob das nun via SMB
läuft oder nicht. Denn alleine "Netzlaufwerk" ist nicht hinreichend -
das kann auch etwas anderes als SMB sein.
Thomas Proppe
Ich meine eher die Einstellung, dass ein Programm (z.B. AutoCAD) gerne
an den letzten benutzten Pfad erinnert und dann erst mal hängt, wenn der
nicht zur Verfügung steht. Ist ja ganz löblich, muss man nicht immer
wieder alles durchtickern. Hat man aber zuletzt auf eine
Netzwerk-Ressource zugegriffen, dauert es gefühlte 20-40 Sekunden, bis
das System meldet, dass der Pfad nicht zur Verfügung steht und auf den
Standardpfad ausweicht.
Wenn die Zeit zu kurz bemessen wäre, ist das ja auch hinderlich, aber
10Sek für die Prüfung ob ein Pfad verfügbar ist, erschien mir schon
angemessen. Aber scheinbar hat Windows da keinen Registry-Eintrag
anzubieten. (Hoffentlich korrigiert mich da einer :-)
Thomas
Christoph
Registry weiß ich jetzt nix aus dem Hut. Was du machen könntest,
ist ein Script schreiben, das folgendes tut:
- Prüfe ob Netz-Laufwerk existiert.
wenn ja: Ende
Wenn nein: Setze ein Subst für den betroffenen
Laufwerksbuchstaben auf ein lokales Verzeichnis.
Kann natürlich sein, dass manche Programme dann immer noch
austicken, weil sie ihre Dateien nicht wiederfinden. Vielleicht
kann man das programmspezifisch abstellen?
Michael Landenberger
> Was eben nicht anders geht, wenn der Zugriffsversuch eine benötigte
> aber nicht verfügbare Ressource potentiell bis zu einer Minute lang
> keine Antwort liefert.
Der Grund, warum dieser Zugriffsversuch keine Antwort liefert, heißt
zumindest in meinem Fall in 99,9999% aller Fälle "Host offline". Wenn man
nun vor dem Zugriffsversuch zunächst prüft, ob der Host erreichbar ist, und
diese Prüfung erheblich schneller vonstatten geht, dann lässt sich der
Timeout erheblich abkürzen. Man greift dann einfach nicht auf die Ressource
zu, nachdem man festgestellt hat, dass das wegen "Host offline" sowieso
sinnlos wäre. Und schon hat man ein großes Windows-Ärgernis aus dem Weg
geräumt.
> Damit vermischt Du aber heftig völlig verschiedene Ebenen - und musst
> abhängig vom Dateinamen mehr oder weniger "raten", ob das nun via SMB
> läuft oder nicht. Denn alleine "Netzlaufwerk" ist nicht hinreichend -
> das kann auch etwas anderes als SMB sein.
Mein Programm prüft nur, ob der (UNC-)Dateipfad mit "\\" anfängt. In diesem
Fall wird das beschriebene Verfahren angewandt, sonst nicht. Bisher
funktioniert das perfekt, und zwar nicht nur bei Windows-Hosts, sondern auch
bei den USB-Dateifreigaben auf einer Fritzbox und bei einem Linux-NAS mit
Samba.
Gruß
Michael
Arno Welzel
> "Arno Welzel" <use...@arnowelzel.de> schrieb:
>
[...]
>> Damit vermischt Du aber heftig völlig verschiedene Ebenen - und musst
>> abhängig vom Dateinamen mehr oder weniger "raten", ob das nun via SMB
>> läuft oder nicht. Denn alleine "Netzlaufwerk" ist nicht hinreichend -
>> das kann auch etwas anderes als SMB sein.
>
> Mein Programm prüft nur, ob der (UNC-)Dateipfad mit "\\" anfängt. In diesem
Was kein ausreichendes Merkmal SMB oder UNC ist.
Siehe dazu auch:
<http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx>
Tatsächlich kann man mit der Syntax "\\?\..." auch angeben, dass direkt
auf das Dateisystem zugegriffen werden soll - z.B. wenn man Dateien mit
reservierten Namen wie "PRN" o.Ä. erzeugen oder lesen möchte - z.B. als
"\\?\C:\PRN".
In der Praxis wird sowas in der Tat sehr selten vorkommen - Du solltest
aber diesen Fall aber zumindest berücksichtigen.