![]() |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Also das hört sich so an als würde der UDPClient irgenwie aussetzen.
Ich hatte das mal mit dem TCPClient und bei mir wahr das das die Netztwerkkarte irgendwann in den Energiesparmodus geschlatet hat, nachdem ich das in der Netzwerkkarte abschaltet hatte wahr das weg. |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Um Gottes Willen. Das fehlte mir gerade noch. Naja aber die Karte schläft doch nur ein, wenn kein Traffic ist...Oder? Wir haben hier maximal ne Pause von 20 Minuten. Ansonsten herscht in dem Netzwerk Dauerbetrieb. Ist aber ein Interessanter Ansatz.
|
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Ich würde mal den gesamten Netzwerkverkehr mit Ethereal sniffen ... dazu muss die Infrastruktur über einen Hub laufen, oder du verwendest Cain und ARP-Spoofing damit alle Daten über einen bestimmten PC laufen (könnte das Ergebnis verfälschen) ...
Dann kannst du kontrollieren, ob die Pakete ins Netz rausgehen, und ob eine Antwort kommt und nur nicht verarbeitet wird ... Evtl. richtest du noch ein, dass bei erhalt einer Nachricht eine Message an den Absender geschickt wird ... dann siehst du beim Sniffen gelich, auf wessen Seite die Antwort fehlt. mfG Markus |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Puh Sniffen und Etheral lese ich heute zum erstenmal. Aber selbst wenn ich weiss, welcher Client nicht mehr reagiert bringt mich das doch nur bedingt weiter, weil die Komponente selbst ja aktiv zu sein scheint. Wie soll ich darauf reagieren?
Ich habe da 2 Ansätze: 1. Ich lass ein Extra-Tool mitlaufen, welches per UDP-Befehl die Client-Software restartet. Dies setzt natürlich voraus, dass dieses Tool auch auf das UDP-Protokoll anspringt und sich nicht auch noch aufhängt... :wink: 2. Ich gehe persönlich zu dem Client und reboote ihn... Ist beides nicht so prall oder? Ich habe leider nicht viel Ahnung vom Sniffen etc...Ich kann natürlich ein Tool mitlaufen lassen, welches alles protokolliert, aber ich zeichne ja schon am Haupttool den Ausgang komplett mit. Dat Ding is stabil und wie schon erwähnt - Gestern abend liefen nach 12 Stunden noch 4 von 9. Es funzt also grundsätzlich, ist aber sehr unstabil. Steigt ein Client einmal aus, dann auch für immer bis zur Termination... |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Ein Sniffer ist ein Programm, welches den Netzwerkverkehr mitschneidet ...
Das hat folgenden Vorteil ... du kannst zurzeit nicht garantieren, dass die Nachrichtenpackete bei den Clients angekommen sind ... mit einem Sniffenden PC kannst du verfolgen, welche Datenpackete von Wo nache Wo gehen ... Dann hast du den Beleg, dass die Daten am Ziel ankommen ... es könnte genausogut sein, dass sich dein Server verschluckt und die Daten gar nicht rausgehen ... Das Problem ist, dass dein Haupttol ja evtl. einen Fehler macht ... deshalb ist eine unabhängige und sicher Funktionierende kontrolle praktisch. mfG Markus |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Zitat:
Aber da ich ja weiss, welche Clients nicht mehr laufen, kann ich vielleicht VIA Netzwerk die Applikation beenden und neu starten??? Das würde mir schon sehr weiterhelfen. Ginge das? Ich weiss neue Frage - neuer Thread, aber in diesem Fall hängt das irgendwie zusammen... |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Dazu bräuchtest du aber eine ständig offen Verbindung, bevorzugt über TCP, um sicherzustellen, dass der CLient reagiert ...
Und wegen dem Sniffer ... ich hab keine Ahnung, wie das UDP-Protokoll genau aufgebaut ist, vielleicht verschluckt sich der Client an einer Überschneidung zwischen senden und empfangen oder so ... ich kenne mich nich so gut auf diesem Gebiet aus ... Vielleicht einfach bei den Clients alle ... 5 Min einen zweiten Sender/Empfänger starten, und dann den alten Auflösen ... mfG Markus |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Ich schau mal, wie ich das lösen kann...
BTW. Seit 2,5 Stunden läuft alles stabil...keiner ausgestiegen... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:23 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz