Ein Online-Datenerfassungssystem besteht aus ca. 30 "echten" Client-PCs (Win XP Embedded) und einer Server-Applikation, die unter Windows 2003 Server auf einer VM läuft. Dieses System arbeitet rund um die Uhr. Die Clients bauen nur sporadisch (alle par Minuten) eine "gehandshakte" UDP-Verbindung auf und senden oder lesen einige hundert Bytes. Nun passiert es seit ca. 14 Tagen so aller 2...3 Tage, das die Kommunikation zwischen den Clients und dem Server komplett versagt, so als ob plötzlich kein UDP mehr transportiert würde. Ein Zusammenhang zu bestimmten Benutzeraktionen kann (bisher) nicht entdeckt werden. Nach mehreren (!) Neustarts der Serverapplikation gehts dann immer wieder. Es gab die letzten zwei Monate kein Update der Server-Applikation, so dass versehentlich eingabute Programmfehler eher unwahrscheinlich sind. Es hat den Anschein, als ob irgendwelche Puffer vollaufen, bis dann Nichts mehr geht. Als Anwendungsentwickler habe ich nicht so den tiefen Einblick in die Windows-Innereien. Ist irgenjemandem etwas bekannt, dass UDP-Kommunikation mit VMs oder nach einem der jüngsten Windows-Updates irgendwie gestört ist? Der Admin und ich - wir versichern uns inzwischen gegenseitig in immer harscher werdendem Ton, dass wir Nichts geändert hätten. Vor dieser Zeit lief die Anwendung mehrere Wochen störungsfrei ...
udp verbindungen sind per definition keine sicheren verbindungen. d.h. es gibt weder eine garantie das die daten ankommen, noch das daten, die ankommen, richtig sind, noch das der sender eine nachricht über das nicht ankommen bekommt. möchtest du all das haben, dann musst du zu tcp wechseln.
__tom schrieb: > noch das daten, die > ankommen, richtig sind, Wenn Daten ankommen, sind sie immer richtig, Ethernetframes haben ein CRC, UDP selbst meistens auch noch. Fehlerhafte Frames verwirft der Stack. Die Reihenfolge kann aber falsch sein, wenn mehrere Wege durch das Netz möglich sind. Das ab und zu UDP Frames verloren gehen, ist normal. Zu viele verlorene Frames können auf Überlastungen in einem Switch hindeuten. MfG Klaus
schau mal mit netstat -a -n oder im Taskmanager bei den Handels nach ob eventuell die Port nicht richtig geschlossen werden. Nicht das Windows die Handls ausgehen.
Klaus schrieb: > Wenn Daten ankommen, sind sie immer richtig, Aus Interesse würde ich mal ping -t auf das Ziel einige Zeit laufen lassen um offensichtliche Paketverluste zu sehen.
Rolf schrieb: > Klaus schrieb: >> Wenn Daten ankommen, sind sie immer richtig, > > Aus Interesse würde ich mal ping -t auf das Ziel einige Zeit laufen > lassen um offensichtliche Paketverluste zu sehen. Was mir gerade noch einfällt: wenn das Netz stark gestört ist, ich meine hier physikalisch, und damit viele Frames fehlerhaft sind, merkt man das bei UDP nicht, es sieht dann so aus, als ob es unterbrochen ist. Die fehlerhaften Frames werden ja schon im Stack verworfen. Wireshark kann das Interface im promiscuous mode betreiben und sollte die Frames trotzdem zeigen. Man könnte wireshark also eine Weile parallel zu Server betreiben und sehen ob man so eine Ursache findet. MfG Klaus
Klaus schrieb: > Was mir gerade noch einfällt: wenn das Netz stark gestört ist, ich meine > hier physikalisch, und damit viele Frames fehlerhaft sind Gemanagten Switch fragen, der führt Statistik über sowas. Evtl. auch entsprechende Support-Software / erweiterter Treiber vom PC-Adapter.
Im Eingangs-Posting schrieb ich ja nicht aus Spaß von "gehandshaktem" UDP. Ich habe ein simples Protokoll implementiert, dass normalerweise den Datenfluss recht zverlässig steuert. Gehen Datagramme verloren, werden sie bei Ausbleiben der Quittung wiederholt - DAS ist nicht das Problem. Das Problem ist, dass die UDP-Kommunikation nach einiger Zeit komplett abstirbt, so als hätte jemand eine Firewall eingeschaltet, die genau das tut: UDP unterbinden. Würden einfach nur Datagramme verloren gehen, selbst wenn es 90% wären, würde die Kommunikation langsam weiterlaufen, evtl. immer schleppender werden, aber nicht von einem Moment auf den anderen vollkommen blockieren ... Andere Protokolle, z.B. RDP oder VNC für den Zugriff auf diesen Server laufen dagegen ungestört weiter.
Frank Esselbach schrieb: > Gehen Datagramme verloren, > werden sie bei Ausbleiben der Quittung wiederholt - DAS ist nicht das > Problem. Versuch herauszufinden, was verloren geht. Es können die Datagramme verloren gehen -> keine Quittung, Wiederholung geht verloren, ... oder Datagram kommt an, Quittung geht verloren, Wiederholung ... Damit kannst du das Problem eingrenzen. Ich würde auf jeden Fall einen Monitor wie wireshark auf dem Server mitlaufen lassen. Wenn das nicht geht, könnte man den Port des Switches, an dem der Server hängt, auf einen anderen Port spiegeln, und dort einen Monitor mitlaufen lassen. Im jetzigen Zustand hast du zuviele Spieler in deinem System. Auch der Hinweis von Peter II bezügl. der Handels könnte hilfreich sein. Ich bin eigentlich ein UDP Fan. Leider hilft einem die socket library dabei nicht sehr. Bei manchen Stacks bekommt man einen send positiv quittiert, obwohl das Interface down ist. MfG Klaus
ich würde auch auf ein Resourcen Problem tippen und erstmal mit Boardmitteln kontrollieren. Im Taskmanager dazu die Spalten priv. Arbeitsspeicher, EA Bytes, Threads, Handles usw. aktivieren. Vielleicht lief die App früher vermeintlich besser weil mehr Speicher (Auslagerungsspeicher) vorhanden war? Windows Eventlogs kontrollieren sollte auch Routine sein.
Frank Esselbach schrieb: > aber nicht von einem Moment auf den > anderen vollkommen blockieren wenn du die möglichkeit hast, dann mit einem netzwerksniffer (tcpdump, wireshark) lauschen ob die pakete überhaupt am server ankommen. es gibt auch ping-tools die anstatt icmp nachrichten udp pakete verwenden. wenn vorhanden, virenkiller testweise abschalten, das hatte ich schon bei 2 kunden das der virenwächter der meinung war er müsse wahllos verbindungen beenden (waren allerdings tcp connects).
Frank Esselbach schrieb: > Ich habe ein simples Protokoll implementiert, dass normalerweise > den Datenfluss recht zverlässig steuert. Ah, du hast TCP neu erfunden. ;-) Neugierig: warum denn eigentlich?
Schon mal andere Netzwerkkarte und neues Kabel probiert? In einem von 100 ganz dummen Fällen hat das auch schon geholfen.
oszi40 schrieb: > Schon mal andere Netzwerkkarte und neues Kabel probiert? In einem von > 100 ganz dummen Fällen hat das auch schon geholfen. sehr unwarscheinlich, es soll ja nach neustart der anwendung wieder gehen. Davon bekommt der Treiber und die Netwerkkarte aber nichts mit. Wird wohl ein normaler Softwarefehler in der Anwendung sein.
Jörg Wunsch schrieb: > Ah, du hast TCP neu erfunden. ;-) Neugierig: warum denn eigentlich? Ich weiß nicht, was Frank motiviert hat, das so zu lösen. Ich hab was ähnliches gebaut aus folgenden Gründen: UDP ist message orientiert, TCP stream. Bei TCP muß ich den Anfang und das Ende einer Nachricht aus dem Inhalt entnehmen, und muß damit rechnen, daß die Nachricht fragmentiert ist. Wenn der Client eigene Aufgaben hat ist es einfacher, eine Message abzuschicken, ein Flag für "Quittung ist noch offen" zu setzen, und weiterzumachen. Bei TCP kann ein (erfolgloser) Verbindungsaufbau lange dauern (2 bis 3 stelliger Sekundenbereich). Damit der Client weiterarbeiten kann, muß die TCP Connection in einem eigenen Thread (oder Task) laufen, sonst blockiert der Client. Bei Problemen kann ein Socket auch schon mal minutenlang blockiert sein. Beim Server ist es ähnlich. Wenn ich mit 30 Clients rechne, muß ich den Server entweder 30 mal starten (oder mich von sowas wie inetd starten lassen). Dann wirds aber mit gemeinsamen Daten problematisch. Oder ich ermögliche 30 Threads innerhalb des Servers, mit allen Konsequenzen bei der Datensynchronisation. UDP ist da viel einfacher. Der Stack serialisiert die Messages für mich. Sie sind nie fragmentiert (auf der Leitung möglicherweise, aber nicht am Socket). Ich kann sie bearbeiten und direkt dem Absender quitieren. Dies waren einige meiner Überlegungen, UDP gegenüber TCP den Vorzug zu geben. MfG Klaus
Jörg Wunsch schrieb: > Ah, du hast TCP neu erfunden. ;-) Neugierig: warum denn eigentlich? "Stehende" TCP-Verbindungen brauchen eine Menge Resourcen auf der Serverseite und wie bereits bemerkt, führen Verbindungs-Störungen zu hässlichen Hängern. Mit meiner UDP-Klasse landen (im Normalfall) alle eingehenden Messages schön in einer Warteschlange, von der sie in Ruhe gelesen und nach und nach abgearbeitet und beantwortet werden können. Es gibt zwei Arten von Messages, die Kommunikation wird immer vom Client ausgelöst. Entweder will dieser etwas vom Server wissen, dann ist die Antwort der Handshake. Will er etwas auf dem Server schreiben, wartet der Client auf ein simples "OK" als Antwort. Nicht beantwortete Messages werden nach ca. 10 Sekunden vom Client wiederholt. Bei Lese-Anforderungen ist das nicht weiter schlimm. Damit Schreib-Aufräge aber nicht mehrfach ausgeführt werden, hat jede Message eine Nummer, die sich der Server merkt, sobald er sie ausführt. Kommt die selbe Aufforderung (mit der gleichen Nummer) nochmal beim Server an, gibts als Antwort nur ein "OK", ohne sie nochmal auszuführen ... Mein System arbeitet auch unter Stress bis zu mehreren Tagen einwandfrei, um dann plötzlich irgendwann "durchzudrehen". Ein simpler Programmierfehler sollte sich eigentlich wesentlich früher zeigen. Der Fehler ist entweder extrem exotisch oder es sind eben Fremdeinflüsse, die ich noch nicht erkannt habe. Ich habe sowohl Server als auch Client über mehrere Stunden mit dem Taskmanager beobachtet, ohne Auffälligkeiten zu bemerken. Weder steigt der Speicherbedarf kontinuierlich an, noch die Zahl der Handles. Die Server-Applikation benötigt z.B. ca. 30 MB und belegt konstant um die 150 Handles. Netzwerktools installieren und Konfigurationen an den Switches vornehmen ist etwas kompliziert, weil ich derzeit nur über RDP Zugriff habe.
Mach mal auf Deiner Maschine, auf der der Server läuft, einen Email-Client oder irgendwas anderes rein, das Verbindungen nach aussen öffnet. Ich ärgere mich mit einem Zyxel VDSL-Router rum, bei dem man ab und zu (spätestens nach 1-3 Tagen) die Leitung so von innen "durchblasen" muss, damit bestehne NATings erhalten bleiben. Dies muss durch den selben Host geschehen, für den das NATing stattfindet. Ist ein FW-Bug. Schau mal im Log nach, was der Router zu den verlorenen Paketen meint.
Klaus schrieb: > Beim Server ist es ähnlich. Wenn ich mit 30 Clients rechne, muß ich den > Server entweder 30 mal starten (oder mich von sowas wie inetd starten > lassen). Dann wirds aber mit gemeinsamen Daten problematisch. Oder ich > ermögliche 30 Threads innerhalb des Servers, mit allen Konsequenzen bei > der Datensynchronisation. nein, man kann ohne Problem 30 server sockets in einen Thread bearbeitet. dafür. Man kann TCP auch non-blocket benutzten!
Peter II schrieb: > nein, man kann ohne Problem 30 server sockets in einen Thread > bearbeitet. dafür. Man kann TCP auch non-blocket benutzten! Einen Code der mit 30 Connections in den verschiedensten Zuständen gleichzeitig jongliert möchte ich nicht debuggen. MfG Klaus
Klaus schrieb: > Einen Code der mit 30 Connections in den verschiedensten Zuständen > gleichzeitig jongliert möchte ich nicht debuggen. wo ist der unteschied ob man es in 30 Threads oder in einem macht? Für jede verbindung legt man sich eine Struktur oder ein Objekt an und fertig. Schwer wird es nur wenn man dinge machen muss die blockierend sind, dann geht auf allen verbindungen nichts mehr. Aber das Problem gibt es bei UDP mit einen Thread genauso.
Frank schrieb: > Nach mehreren (!) Neustarts der Serverapplikation gehts dann net statistics -? Wäre auch mal zu prüfen, ob das Übel nur zu bestimmen Zeiten auftritt, um so den Fehler einzukreisen. Evtl. ist irgendwo eine neue Maschine aufgetaucht, die Störungen im LAN verursacht?
Frank Esselbach schrieb: > "Stehende" TCP-Verbindungen brauchen eine Menge Resourcen auf der > Serverseite und wie bereits bemerkt, führen Verbindungs-Störungen zu > hässlichen Hängern. Nun ja. Aktuell debuggst du aber gerade UDP-Hänger. ;-) Das allein widerspricht dem bereits. So ähnlich wie du hat NFS anfangs auch argumentiert. Die sind schon vor 10 Jahren davon abgekommen und benutzen seither TCP, weil es sinnvoller ist, dass sich gut ausgefeilte und über Jahrzehnte etablierte Algorithmen darum kümmern, die Daten auch unter schwierigen Bedingungen auszuliefern, anstatt vergleichbare Algorithmen in jeder Applikation aufs Neue implementieren zu wollen. Ich würde mal behaupten, dass du bei TCP erst in Probleme laufen würdest bei einer Verbindungsqualität, bei der deine UDP-Implementierung sowieso schon am Verzweifeln wäre. Dinge wie ein Timeout bei Verbindungsaufnahme sollten in einem modernen TCP-Stack einstellbar sein.
Peter II schrieb: > wo ist der unteschied ob man es in 30 Threads oder in einem macht? Für > jede verbindung legt man sich eine Struktur oder ein Objekt an und > fertig. Da man non blocking arbeiten muß, muß man dann alle pollen, mit allen Konsequenzen. Wenn man das dann fertig entworfen hat, hat man eigentlich Threads neu erfunden. Da nehm ich doch lieber die von anderen schon verifizierten Threadfunktionen. Peter II schrieb: > Aber das Problem gibt es bei > UDP mit einen Thread genauso. Da UDP Verbindungslos ist, geht das so wie du beschrieben hast, Struktur/Objekt pro Client, alles non blocking. Der klassische TCP-Server, der HTTP Server lief früher als eine Task pro Connection und ließ sich via inetd vielfach starten. Später ging man dazu über, inetd außen vor zu lassen. IMHO ist die aktuelle Strategie bis zu einer gewissen Anzahl von Verbindungen Threads zu verwenden, und wenn mehr gebraucht wird, eine weitere Task zu starten.
UDP kann dennoch nützlich sein wenn man ein Broadcast realisieren will, ich benutz dafür ganz gerne JGroups.
Läubi .. schrieb: > UDP kann dennoch nützlich sein wenn man ein Broadcast realisieren will, Ja, aber das ist so fast der einzige Fall, bei dem es wirklich noch Sinn hat. Oder, wenn man in kurzer Zeit viele verschiedene Server nach ein und demselben Fragen will (DNS), oder wenn es tatsächlich auf ein möglichst exaktes Timing ankommt (NTP). Selbst bei DNS werden aber Antworten, die die Größe eines Antwortpakets übersteigen, per TCP abgeholt (weil man an dieser Stelle ja bereits einen Server kennt, von dem man weiß, dass er gewillt ist, die Daten zu liefern). Das sind so die einzigen UDP-basierten Protokolle, die mir auf Anhieb einfallen. Ach ja, multicast-basierte Dinge natürlich noch, bei denen das "Streamen" der Daten wichtiger ist als die Integrität.
Sowie alle Echtzeitprotokolle wie VoIP aka RTP und (außer bei MS) SIP und NFS ... MfG Klaus
Klaus schrieb: > Sowie alle Echtzeitprotokolle wie VoIP aka RTP Ja, da ist das Zeitverhalten kritischer als die Datenintegrität. Wenn ein Paket weg ist, ist es weg, es nützt ohnehin nichts, wenn es erst 3 s später nachgeliefert wird. > und (außer bei MS) SIP Für das reine signalling gibt's eigentlich keinen Grund, UDP zu benutzen. Folgerichtig ist SIP auch auf beiden genormt. > und NFS ... Nein, siehe oben. Das war vor 10 Jahren. Heutzutage wird NFS standardmäßig über TCP erledigt.
Also wieder so ein Fall von 'Ich kann keine Zustandsautomaten programmieren'? Irgendwer hatte schon vor Jahrzehnten mal gesagt: Niemand braucht Threads. Threads sind für Leute, die keine Zustandsautomaten bauen können. Und er hatte Recht ;-) In der Tat wird UDP aber gerade wieder ganz stark ausgegraben für Multicast und Streaming. Da aber hauptsächlich, um Protokolloverhead zu sparen und weil es beim Streaming ohnehin witzlos ist, Pakete erneut anzufordern. Wenn im Echtzeit-Stream ein Päckchen fehlt, ruckelts oder knallts halt gerne. Wegen der stehenden Verbindungen: Oft geht man da mehrspurig heran. Apache lässt z.B. mit prefork mal eine Reihe von Prozessen vom Stapel, die dann auf Verbindungen warten. Mit worker macht er genau das: Eine Handvoll Prozesse, jeweils mit vielen Threads.
Sven P. schrieb: > Irgendwer hatte schon vor Jahrzehnten mal gesagt: Niemand braucht > Threads. Threads sind für Leute, die keine Zustandsautomaten bauen > können. Und er hatte Recht ;-) ich habe beides schon gemacht, da aber heute fast jeders notebook schon 4CPUs hat, kann man mit Threads mehr leistungs rausholen. Auf eine Single-Core ist die Lösung mit nur einen Threads sogar schneller weil es weniger Taskwechsel gibt,
Das ist vollkommen korrekt, fällt aber für meine Begriffe in die MPM-Kiste. Der OT schrob oben: - ...ca. 30 "echten" Client-PCs - ...(Win XP Embedded) - ...(alle par Minuten) - ...oder lesen einige hundert Bytes. All das spricht irgendwie aber gegen MPM, viel Leistung und so weiter. Da würde vermutlich mehr Leistung bei der Threadverwaltung und beim synchronisieren der Speicherzugriffe flöten gehen, als durch Mehrkernauslastung gewonnen wäre.
Sven P. schrieb: > Irgendwer hatte schon vor Jahrzehnten mal gesagt: Niemand braucht > Threads. Threads sind für Leute, die keine Zustandsautomaten bauen > können. Und er hatte Recht ;-) Naja, und außerdem sind sie was für Betriebssysteme, deren Prozess- wechselgeschwindigkeit eher an Schildkröten denn Gazellen erinnert. ;-) Wenn Frank bei der bestehenden UDP-Lösung bleiben will/muss, dann wird wohl um ausgedehnte Sitzungen mit wireshark & Co. auf beiden Seiten kein Weg drumrum führen. Allerdings wird wohl die Auswertung der Suche einer Nadel im Heuhaufen gleichen. Gut synchronisierte Uhren auf beiden Seiten können bei der Auswertung recht hülfreich sein.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.