Hallo,
nur eine kurze Frage: hat schon mal jemand mit diesem Modul
(mit dem man in Perl Win32 Services schreiben kann) gearbeitet?
Ich habe ein Problem mit einer seiner Funktionen, aber bevor ich
ins Detail gehe, möchte ich nur abklären, ob das Modul überhaupt
jemand kennt.
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Ferry Bolhar wrote:
> Hallo,
>
> nur eine kurze Frage: hat schon mal jemand mit diesem Modul
> (mit dem man in Perl Win32 Services schreiben kann) gearbeitet?
>
> Ich habe ein Problem mit einer seiner Funktionen, aber bevor ich
> ins Detail gehe, möchte ich nur abklären, ob das Modul überhaupt
> jemand kennt.
Jep, ich benutze es für eine Reihe von Selbstbau-Windows-Services.
Gruß
Thomas
--
$/=$,,$_=,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~...... >r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k ^.-
Thomas Kratz:
>> Ich habe ein Problem mit einer seiner Funktionen, aber bevor ich
>> ins Detail gehe, möchte ich nur abklären, ob das Modul überhaupt
>> jemand kennt.
>
> Jep, ich benutze es für eine Reihe von Selbstbau-Windows-Services.
Das mache ich auch. Ich möchte außerdem die Möglichkeit vorsehen,
abzufragen, auf welchen Rechnern diese Services gerade laufen. Ich
dachte, dass ich das mit der
Win32::Daemon::SetServiceBits()
Funktion erreichen kann. Verwendest du vielleicht auch diese
Funktion?
LG, Ferry
--
Ferry Bolhar schrieb:
> Thomas Kratz:
>
>>> Ich habe ein Problem mit einer seiner Funktionen, aber bevor ich
>>> ins Detail gehe, möchte ich nur abklären, ob das Modul überhaupt
>>> jemand kennt.
>> Jep, ich benutze es für eine Reihe von Selbstbau-Windows-Services.
>
> Das mache ich auch. Ich möchte außerdem die Möglichkeit vorsehen,
> abzufragen, auf welchen Rechnern diese Services gerade laufen. Ich
> dachte, dass ich das mit der
>
> Win32::Daemon::SetServiceBits()
>
> Funktion erreichen kann. Verwendest du vielleicht auch diese
> Funktion?
Es wird an Deiner Abfrage liegen. Versuche es lokal und taste Dich dann vor:
Win32::NetAdmin::GetServers('', '', USER_SERVICE_BITS_1,$server_aref)
funktioniert jedenfalls bestens.
Gruß,
Peter
Peter Arnhold:
> Es wird an Deiner Abfrage liegen. Versuche es lokal und taste Dich dann
vor:
> Win32::NetAdmin::GetServers('', '', USER_SERVICE_BITS_1,$server_aref)
> funktioniert jedenfalls bestens.
Rufst du Win32::Daemon::SetServiceBits() auf, bevor du dein
Service startest oder danach?
Oder einfacher: hast du ein funktionierendes Code-Beispiel für
den Aufruf von SetServiceBits()?
Danke, Prosit Neujahr und schöne Grüße aus Wien,
Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
[...]
Win32::Daemon::AcceptedControls(
SERVICE_ACCEPT_SHUTDOWN | SERVICE_ACCEPT_STOP
);
Win32::Daemon::StartService();
Win32::Daemon::SetServiceBits(USER_SERVICE_BITS_1);
$prev_state = SERVICE_START_PENDING;
[...]
Ich benutze das nicht. Ich habe SetServiceBits einfach mal dazu gebastelt. Es
ging auf Anhieb, setzen und abfragen. Aber mangels PDC nur lokal getestet.
Hast Du denn mal versucht, eine andere Eigenschaft abzufragen, z.B.
SV_TYPE_WORKSTATION? Geht nur USER_SERVICE_BITS_X nicht? Ich kann es Mi in der
Firma testen.
Guten Rutsch!
Ferry Bolhar schrieb:
> Peter Arnhold:
>
>> Es wird an Deiner Abfrage liegen. Versuche es lokal und taste Dich dann
> vor:
>> Win32::NetAdmin::GetServers('', '', USER_SERVICE_BITS_1,$server_aref)
>> funktioniert jedenfalls bestens.
>
> Rufst du Win32::Daemon::SetServiceBits() auf, bevor du dein
> Service startest oder danach?
>
> Oder einfacher: hast du ein funktionierendes Code-Beispiel für
> den Aufruf von SetServiceBits()?
>
> Danke, Prosit Neujahr und schöne Grüße aus Wien,
>
> Ferry
>
Es geht, aber nur mit freiem 1. Parameter:
Win32::NetAdmin::GetServers('', 'XXX-BLN', USER_SERVICE_BITS_1,$server_aref);
Ich kenne mich mit Win32::NetAdmin nicht aus und kann nicht sagen, warum das so
ist.
Peter Arnhold schrieb:
> [...]
> Win32::Daemon::AcceptedControls(
> SERVICE_ACCEPT_SHUTDOWN | SERVICE_ACCEPT_STOP
> );
> Win32::Daemon::StartService();
> Win32::Daemon::SetServiceBits(USER_SERVICE_BITS_1);
> $prev_state = SERVICE_START_PENDING;
> [...]
>
> Ich benutze das nicht. Ich habe SetServiceBits einfach mal dazu gebastelt. Es
> ging auf Anhieb, setzen und abfragen. Aber mangels PDC nur lokal getestet.
>
> Hast Du denn mal versucht, eine andere Eigenschaft abzufragen, z.B.
> SV_TYPE_WORKSTATION? Geht nur USER_SERVICE_BITS_X nicht? Ich kann es Mi in der
> Firma testen.
>
> Guten Rutsch!
>
>
> Ferry Bolhar schrieb:
>> Peter Arnhold:
>>
>>> Es wird an Deiner Abfrage liegen. Versuche es lokal und taste Dich dann
>> vor:
>>> Win32::NetAdmin::GetServers('', '', USER_SERVICE_BITS_1,$server_aref)
>>> funktioniert jedenfalls bestens.
>> Rufst du Win32::Daemon::SetServiceBits() auf, bevor du dein
>> Service startest oder danach?
>>
>> Oder einfacher: hast du ein funktionierendes Code-Beispiel für
>> den Aufruf von SetServiceBits()?
>>
>> Danke, Prosit Neujahr und schöne Grüße aus Wien,
>>
>> Ferry
>>
Peter Arnhold:
> Ich benutze das nicht. Ich habe SetServiceBits einfach mal dazu gebastelt.
Es
> ging auf Anhieb, setzen und abfragen. Aber mangels PDC nur lokal getestet.
Aha, ich habe da so eine Vermutung (siehe weiter unten).
> Hast Du denn mal versucht, eine andere Eigenschaft abzufragen, z.B.
> SV_TYPE_WORKSTATION? Geht nur USER_SERVICE_BITS_X nicht?
> Ich kann es Mi in der Firma testen.
Es geht mit anderen Werten durchaus, also mit SV_TYPE_WORKSTATION,
SV_TYPE_DOMAIN_CTRL oder SV_TYPE_SERVER bekomme ich die
entsprechenden System aufgelistet.
Aber ich habe jetzt im MSDN nachgelesen - der "Server" (d.h., der Rechner,
der SetServiceBits() aufruft), muss W2003 oder W2000 Server laufen haben.
Meine Kiste hat nur W2000 Professional. Das dürfte der Grund gewesen
sein.
Typisch, dass ein System API Call OK zurückliefert, obwohl er gar nicht
funktioniert hat!
Naja, jetzt geht es jedenfalls. Vielen Dank an alle, die mir mit Tipps
geholfen
haben. Jetzt muss ich nur mehr schauen, dass das Browsing schneller geht,
denn wenn ich das Service auf einem Rechner starte, dauert es bis zu 30
Minuten, bis es auf anderen Rechnern bekannt ist (und nach dem Stoppen
auch wieder verschwindet). Vermutlich gibt's da eine Verzögerung beim
Announcement solcher Services innerhalb einer Domaine.
Nochmals Danke & LG,
Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Ferry Bolhar schrieb:
> Aber ich habe jetzt im MSDN nachgelesen - der "Server" (d.h., der Rechner,
> der SetServiceBits() aufruft), muss W2003 oder W2000 Server laufen haben.
> Meine Kiste hat nur W2000 Professional. Das dürfte der Grund gewesen
> sein.
>
>
> Typisch, dass ein System API Call OK zurückliefert, obwohl er gar nicht
> funktioniert hat!
>
Ich finde die Erkenntnis beachtlich. Meine beiden Testrechner waren eine XP-
und eine W2k Professional Workstation! Das OK der API war wohl wirklich ok.
Außerdem musst Du eventuell unterscheiden zwischen dem Setzen und dem
Mechanismus zur Bekanntgabe. Ich denke nachwievor, Win32::Daemon hat damit
nichts zu tun und arbeitet korrekt.
> Naja, jetzt geht es jedenfalls. Vielen Dank an alle, die mir mit Tipps
> geholfen
> haben. Jetzt muss ich nur mehr schauen, dass das Browsing schneller geht,
> denn wenn ich das Service auf einem Rechner starte, dauert es bis zu 30
> Minuten, bis es auf anderen Rechnern bekannt ist (und nach dem Stoppen
> auch wieder verschwindet). Vermutlich gibt's da eine Verzögerung beim
> Announcement solcher Services innerhalb einer Domaine.
Die Abfrage in o.g. Teststellung war sofort nach Dienstestart positiv und
sofort nach Beendigung ohne Ergebnis, also auch völlig korrekt.
Vielleicht ist der Mechanismus sowieso nicht dafür gedacht, wofür Du es nutzen
willst. Soweit ich die von MS reservierten Flags kenne, handelt es sich am Ende
um eine Eigenschaft, die ein Host annimmt und nicht um ein Auskunftssystem für
temporär laufende Dienste. Es kann auch niemand garantieren, dass Programme von
Drittanbietern nicht gleiche Bits setzen. Hast Du dich damit beschäftigt, wofür
das ursächlich geschaffen wurde und ob es vom Ansatz zu dem passt, was Du
machen willst?
Gruß,
Peter
Peter Arnhold:
> Ich finde die Erkenntnis beachtlich. Meine beiden Testrechner waren eine
XP-
> und eine W2k Professional Workstation! Das OK der API war wohl wirklich
ok.
Dann kann ich es mir nur so erklären, dass du lokal - d.h., ohne Domain-
Controller - getestet hast. Möglicherweise weist der Domain-Controller
den Request, das jeweilige Bit zu setzen, für den Rechner zurück, wenn
dieser nicht das passende OS hat (oder er unterbindet zumindest das
Advertisment); lokal wird das sichtlich nicht geprüft. Leider ist das - wie
so oft im Falle von MS - nirgendwo dokumentiert.
> Außerdem musst Du eventuell unterscheiden zwischen dem Setzen und dem
> Mechanismus zur Bekanntgabe. Ich denke nachwievor, Win32::Daemon hat damit
> nichts zu tun und arbeitet korrekt.
Ja, das andere dürfte über irgendeine Verteilung ablaufen. Interessant
ist, dass der entsprechende W32 Systemcall ein Flag für "update
immediately" hat. Ist das Flag gesetzt, wird das Update (durch das
Server Service) sofort veranlasst, ansonsten "nicht sofort" (no na).
Offen bleibt, was mit "nicht sofort" gemeint ist. Ich weiß leider nicht,
welche Argumente die Perl-Funktion an das API übergibt.
> Die Abfrage in o.g. Teststellung war sofort nach Dienstestart positiv und
> sofort nach Beendigung ohne Ergebnis, also auch völlig korrekt.
Wie schon gesagt, in einer Domaine sieht es leider anders aus.
Hast du es dort schon probiert?
> Vielleicht ist der Mechanismus sowieso nicht dafür gedacht, wofür Du es
nutzen
> willst. Soweit ich die von MS reservierten Flags kenne, handelt es sich am
Ende
> um eine Eigenschaft, die ein Host annimmt und nicht um ein Auskunftssystem
für
> temporär laufende Dienste. Es kann auch niemand garantieren, dass
Programme von
> Drittanbietern nicht gleiche Bits setzen. Hast Du dich damit beschäftigt,
wofür
> das ursächlich geschaffen wurde und ob es vom Ansatz zu dem passt, was Du
> machen willst?
Naja - ich habe ein Service zur Überwachung bestimmter SW-
Komponenten von Fremdsoftware geschrieben. Was nun noch
gewünscht wird, ist die Möglichkeit, Überwachungsdaten von
anderen Rechnern aus abzufragen. Das mache ich über die Registry,
d.h., die Software speichert ihren Zustand in einem Registry Key,
auf den von anderen Rechnern lesend zugegriffen wird. Ich verwende
Tie::Registry, das funktioniert sehr gut.
Was mir nun noch fehlt, ist die Möglichkeit, festzustellen, wo überall
das Überwachungsservice installiert ist, d.h., wo die Registry
entsprechend abgefragt werden muss. Natürlich könnte ich auch
alle Rechner unserer Domaine entsprechend prüfen, aber bei über
6000 Rechnern (von denen nur auf ein bis zwei Dutzend meine
Software laufen wird) erscheint mir das nicht sehr praktikabel.
Daher dachte ich, ich könnte im Code des Services beim Starten
mit
Win32::Daemon::SetServiceBits(USER_SERVICE_BITS_1);
den Rechner entsprechend kennzeichnen und mir im Abfrage-
programm mit
Win32::Lanman::NetServerEnum("", "Wien1", USER_SERVICE_BITS_1, my \@server);
alle derart markierten Server auf einfache Art holen ("Wien1"
ist der Name der betreffenden Domaine).
Lt. MSDN wird dieses Bit wird von MS nicht verwendet und
steht für Benutzeranwendungen zur Verfügung. Und wie gesagt,
es funktioniert ja im Prinzip auch. Ich muss nur noch heraus-
finden, warum es solange dauert, bis sich in der Domaine das
Erscheinen bzw. Verschwinden des betreffenden Services
herumgesprochen hat, d.h., wie das Advertisment funktioniert.
Habe ich das richtig verstanden: du rufst SetServiceBits() im
Kontext eines Services auf, und sobald du das Service startest,
ist die Abfrage mittels GetServers() erfolgreich? Wie erstellst du
das Service? Mit SRVANY?
Und wenn du das Service stoppst, dann liefert eine neue
Abfrage sofort nichts mehr zurück?
Kannst du deine Skripts auch einmal in einer Domaine
ausprobieren? Es wäre interessant, ob da dasselbe Verhalten
auftritt wie bei mir.
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Ferry Bolhar schrieb:
> Peter Arnhold:
>
>> Ich finde die Erkenntnis beachtlich. Meine beiden Testrechner waren eine
> XP-
>> und eine W2k Professional Workstation! Das OK der API war wohl wirklich
> ok.
>
> Dann kann ich es mir nur so erklären, dass du lokal - d.h., ohne Domain-
> Controller - getestet hast. Möglicherweise weist der Domain-Controller
> den Request, das jeweilige Bit zu setzen, für den Rechner zurück, wenn
> dieser nicht das passende OS hat (oder er unterbindet zumindest das
> Advertisment); lokal wird das sichtlich nicht geprüft. Leider ist das - wie
> so oft im Falle von MS - nirgendwo dokumentiert.
>
>> Außerdem musst Du eventuell unterscheiden zwischen dem Setzen und dem
>> Mechanismus zur Bekanntgabe. Ich denke nachwievor, Win32::Daemon hat damit
>> nichts zu tun und arbeitet korrekt.
>
> Ja, das andere dürfte über irgendeine Verteilung ablaufen. Interessant
> ist, dass der entsprechende W32 Systemcall ein Flag für "update
> immediately" hat. Ist das Flag gesetzt, wird das Update (durch das
> Server Service) sofort veranlasst, ansonsten "nicht sofort" (no na).
> Offen bleibt, was mit "nicht sofort" gemeint ist. Ich weiß leider nicht,
> welche Argumente die Perl-Funktion an das API übergibt.
>
>> Die Abfrage in o.g. Teststellung war sofort nach Dienstestart positiv und
>> sofort nach Beendigung ohne Ergebnis, also auch völlig korrekt.
>
> Wie schon gesagt, in einer Domaine sieht es leider anders aus.
> Hast du es dort schon probiert?
>
>> Vielleicht ist der Mechanismus sowieso nicht dafür gedacht, wofür Du es
> nutzen
>> willst. Soweit ich die von MS reservierten Flags kenne, handelt es sich am
> Ende
>> um eine Eigenschaft, die ein Host annimmt und nicht um ein Auskunftssystem
> für
>> temporär laufende Dienste. Es kann auch niemand garantieren, dass
> Programme von
>> Drittanbietern nicht gleiche Bits setzen. Hast Du dich damit beschäftigt,
> wofür
>> das ursächlich geschaffen wurde und ob es vom Ansatz zu dem passt, was Du
>> machen willst?
>
> Naja - ich habe ein Service zur Überwachung bestimmter SW-
> Komponenten von Fremdsoftware geschrieben. Was nun noch
> gewünscht wird, ist die Möglichkeit, Überwachungsdaten von
> anderen Rechnern aus abzufragen. Das mache ich über die Registry,
> d.h., die Software speichert ihren Zustand in einem Registry Key,
> auf den von anderen Rechnern lesend zugegriffen wird. Ich verwende
> Tie::Registry, das funktioniert sehr gut.
>
> Was mir nun noch fehlt, ist die Möglichkeit, festzustellen, wo überall
> das Überwachungsservice installiert ist, d.h., wo die Registry
> entsprechend abgefragt werden muss. Natürlich könnte ich auch
> alle Rechner unserer Domaine entsprechend prüfen, aber bei über
> 6000 Rechnern (von denen nur auf ein bis zwei Dutzend meine
> Software laufen wird) erscheint mir das nicht sehr praktikabel.
>
> Daher dachte ich, ich könnte im Code des Services beim Starten
> mit
>
> Win32::Daemon::SetServiceBits(USER_SERVICE_BITS_1);
>
> den Rechner entsprechend kennzeichnen und mir im Abfrage-
> programm mit
>
> Win32::Lanman::NetServerEnum("", "Wien1", USER_SERVICE_BITS_1, my \@server);
>
> alle derart markierten Server auf einfache Art holen ("Wien1"
> ist der Name der betreffenden Domaine).
>
> Lt. MSDN wird dieses Bit wird von MS nicht verwendet und
> steht für Benutzeranwendungen zur Verfügung. Und wie gesagt,
> es funktioniert ja im Prinzip auch. Ich muss nur noch heraus-
> finden, warum es solange dauert, bis sich in der Domaine das
> Erscheinen bzw. Verschwinden des betreffenden Services
> herumgesprochen hat, d.h., wie das Advertisment funktioniert.
>
> Habe ich das richtig verstanden: du rufst SetServiceBits() im
> Kontext eines Services auf, und sobald du das Service startest,
> ist die Abfrage mittels GetServers() erfolgreich?
Ja.
> Wie erstellst du das Service? Mit SRVANY?
Nein. Alles komplett über Win32::Daemon (Win32::Daemon::CreateService).
> Und wenn du das Service stoppst, dann liefert eine neue
> Abfrage sofort nichts mehr zurück?
Ja. Ich habe es grade auch noch einmal mit Win32::Lanman::NetServerEnum
getestet. Ich bekomme auch von dem W2k Rechner sofort das Ergebnis und nach dem
Stop sofort kein Ergebnis mehr.
> Kannst du deine Skripts auch einmal in einer Domaine
> ausprobieren? Es wäre interessant, ob da dasselbe Verhalten
> auftritt wie bei mir.
Habe ich. Meine letzten Aussagen bezogen sich auf Tests in einer Domaine. Ist
aber leider nicht unbedingt vergleichbar. Ich habe erfahren, dass unser PDC auf
Linux läuft, nix MS. Außerdem haben wir keine 6000 Rechner, höchstens 50.
Gruß,
Peter
Peter Arnhold:
>> Kannst du deine Skripts auch einmal in einer Domaine
>> ausprobieren? Es wäre interessant, ob da dasselbe Verhalten
>> auftritt wie bei mir.
>
> Habe ich. Meine letzten Aussagen bezogen sich auf Tests in einer Domaine.
Ist
> aber leider nicht unbedingt vergleichbar. Ich habe erfahren, dass unser
PDC auf
> Linux läuft, nix MS. Außerdem haben wir keine 6000 Rechner, höchstens 50.
OK, dann ist das so sicher nicht vergleichbar. Ein "Guru" bei uns hat mir
jetzt verraten, das es in jedem LAN-Segment einen "Master-Browser"
gibt, der für das Sammeln und Verteilen von solchen Informationen
zuständig ist (über Broadcasts). Jeder Rechner sendet dabei alle 12
Minuten seine Informationen an den Broweser. Die Browser tauschen
untereinander und mit dem PDC (das ist der Masterbrowser für eine
Domaine) wiederum alle 12 Minuten Informationen aus. Es kann daher,
wenn der Server, der das USER_SERVICE_BITS_1 setzt, und der
Client, der es abfragt, in unterschiedlichen LAN-Segmenten sind, bis
zu 36 Minuten dauern, bevor das Setzen bzw. Löschen des Bits erkannt
wird. Es gibt natürlich auch einen Mechanismus, das zu beschleunigen,
d.h., die Information wird sofort in der Domaine verfügbar gemacht
(wie das beim Einrichten von Shares der Fall ist). Leider scheint das
hier mit dem SetServiceBits()-Call nicht zu funktionieren. Und es ist
eine Tatsache, dass es von meiner W2k Professional-Kiste überhaupt
nicht funktioniert.
Rufst du SetServiceBits() auf, bevor du das Service startest, oder
danach? Verwendest du die Callback-Funktionalität von Win32::Daemon
oder eine große Schleife?
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Ferry Bolhar schrieb:
> hier mit dem SetServiceBits()-Call nicht zu funktionieren. Und es ist
> eine Tatsache, dass es von meiner W2k Professional-Kiste überhaupt
> nicht funktioniert.
funktioniert bei mir mit:
Windows 2000 Professional Service Pack 2, v.6717
> Rufst du SetServiceBits() auf, bevor du das Service startest, oder
Das ist egal. Es geht in beides.
> danach? Verwendest du die Callback-Funktionalität von Win32::Daemon
> oder eine große Schleife?
Ich benutze generell eine eigene Hauptschleife und keine Callbacks von
Win32::Daemon.
Auch wenn MS garantiert, dass sie selbst die User-Flags nicht benutzen, kann
keiner garantieren, dass Drittanbieter das nicht machen. Vielleicht löst Du das
ganze anders, z.B. über einen UDP-Multicast. Dann könntest Du mit eigenen
Mechanismen, die Du voll unter Kontrolle hast, die nötigen Informationen
einsammeln. Die Zeit, die Du jetzt schon investiert hast, hätte dafür
wahrscheinlich gereicht ;-)
Gruß,
Peter
Peter Arnhold:
> funktioniert bei mir mit:
> Windows 2000 Professional Service Pack 2, v.6717
>
> > Rufst du SetServiceBits() auf, bevor du das Service startest, oder
>
> Das ist egal. Es geht in beides.
Ja - es dauert nur aufgrund des Advertise-Mechanismus, der innerhalb
einer Windows Domaine mit mehreren Collision Domains für das Browsing
verwendet wird, nur u.U. bis zu 30 Minuten, bis es sich zu allen Rechnern
durchgesprochen hat. Darauf war ich nicht gefasst, als ich getestet habe.
Als ich das Service einmal über Nacht laufen gelassen habe, konnte ich
den betreffenden Server mittels Win32::NetServerEnum anstandslos am
nächsten Tag finden. Nach dem Abdrehen des Services dauerte es aller-
dings wieder fast 20 Minuten, bevor sich das in unserer Domaine herum-
gesprochen hatte. Ich bin über diese Verzögerung zwar nicht sehr glücklich,
kann aber damit leben.
>> danach? Verwendest du die Callback-Funktionalität von Win32::Daemon
>> oder eine große Schleife?
>
> Ich benutze generell eine eigene Hauptschleife und keine Callbacks von
> Win32::Daemon.
Aha, ich verwende die Callbacks. Aber ich denke, das macht hier ja
wohl keinen Unterschied.
> Auch wenn MS garantiert, dass sie selbst die User-Flags nicht benutzen,
kann
> keiner garantieren, dass Drittanbieter das nicht machen.
Da hast du recht, ein kleines Restrisiko bleibt. Ich prüfe das über einen
kleinen Registrykey, den mein Service macht, wenn es gestartet wird,
(und beim Stoppen entfernt) nach. Wird ein Rechner zwar gefunden, es
existiert dieser Key aber nicht, wird der Rechner gleich wieder verworfen.
NetServerEnum trifft also hier sozuagen nur eine Vorauswahl. ;-)
> Vielleicht löst Du das ganze anders, z.B. über einen UDP-Multicast.
Über Collision Domains hinweg?
> Dann könntest Du mit eigenen
> Mechanismen, die Du voll unter Kontrolle hast, die nötigen Informationen
> einsammeln. Die Zeit, die Du jetzt schon investiert hast, hätte dafür
> wahrscheinlich gereicht ;-)
Mag sein, aber Multicasts sind in unserem Netzwerk nicht überall hin
möglich, daher würde diese Lösung nicht funktionieren. Außerdem
möchte ich das Rad nicht gerne zum zweitenmal erfinden. Der Browsing-
Mechanismus existiert ja genau für solche Anwendungen.
Danke für deine Antwort & schöne Grüße aus Wien,
Ferry
--
Ing.Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at