Ich habe ein Online-BDE-System etwickelt, bei dem zur Kommunikation zwischen Clients (ca. 30) und Server ein recht komplexes Messaging-Protokoll auf UDP-Basis Verwendung findet (aus einer Fremd-Bibliothek). Der Server läuft auf einer VM unter VM-Ware (Version kenne ich nicht genau, dafür ist der betriebliche Admin zuständig). Im Allgemeinen sind die Datenpakete recht klein (< 1 KB) und es treten keine Kommunikationsprobleme auf. Zu dem System gehört aber auch ein Programm zum Drucken von Betriebsausweisen auf einem Kartendrucker. Beim Start holt sich das Programm z.B. eine Liste der Angestellten - die ist allerdings nun ca. 7 KB groß, und auch die Passbider von ca. 8kb aus der Datenbank. Das lässt vermuten, dass in diesem Falle sog. fragmentierte UDP-Pakete zum Einsatz kommen. Bis vor ca. 14 Tagen funktionierte das Alles einwandfrei. Inzwischen hat der Admin den Server auf eine leistungsfähigere Hardware umziehen lassen, was der Performance des Gesamtsystems durchaus zu Gute kommt. Dummerweise hat er dabei irgend eine Einstellung verpeilt, die nun auf der neuen VM dafür sorgt, dass die großen oder fragmentierten UDP-Pakete nicht mehr durchkommen und das Ausweis-Programm funktionert nicht mehr. Nun gehen ständig Screenshots und Schuldzuweisungen zwischen dem Admin und mir hin und her, ohne dass sich eine Lösung abzeichnet, es entwickelt sich eine gewisse Spannung, was ich auf die Dauer nicht gut finde. Auch ist der Admin ständig überlastet, weil er alleine für drei ziemlich große Firmen zuständig ist und irgendwie keine Lust hat, nach der Ursache für "meinen Scheiss" zu suchen. Hat hier jemand eine Idee, wo genau das verfixte Detail stecken könnte, um dem Admin irgendwie behilflich zu sein und die Sache voranzubringen?
Die Glaskugel sagt: UDP-offloading ist im Server an und macht Probleme. Ältere Hardware hat das oft noch nicht. Ernsthaft: Ohne Wireshark- Dump ist das nur ein wildes Ratespiel, da hätte ich als Admin auch keine Zeit und Lust zu.
Frank Esselbach schrieb: > Auch ist der Admin ständig überlastet, weil er alleine für drei > ziemlich große Firmen zuständig ist und irgendwie keine Lust hat, nach > der Ursache für "meinen Scheiss" zu suchen. Kann ich absolut nachvollziehen. Die Probleme mit UDP hatten wir doch unlängst erst in irgendnem Thread? UDP ist gut für Filmchen gucken, aber Datenbank?? > Hat hier jemand eine Idee, wo genau das verfixte Detail stecken könnte, > um dem Admin irgendwie behilflich zu sein und die Sache voranzubringen? Vielleicht mal an der MTU rumschrauben.
Frank Esselbach schrieb: > Liste der Angestellten - die ist allerdings nun ca. 7 > KB groß, und auch die Passbider von ca. 8kb aus der Datenbank. Das lässt > vermuten, dass in diesem Falle sog. fragmentierte UDP-Pakete zum Einsatz > kommen. UDP ist hierfuer das falsche Protokoll. Sun ist damals beim Sprung von NFSv2 auf NFSv3 auch auf TCP umgestiegen. Warum das Rad neu erfinden und in hoeheren OSI-Schichten checken, ob alle Pakete angekommen sind ?
Wenn man die Kommunikationsstruktur der Anwendung nicht kennt sollte man mit einer pauschalen Verdammung von UDP sehr vorsichtig sein. Nicht immer ist TCP im Vorteil.
Jim Meba schrieb: > Die Glaskugel sagt: UDP-offloading ist im Server an und macht Probleme. > Ältere Hardware hat das oft noch nicht. Ob in einem Server einzelne Funktionen des Stacks im Adapter oder im Betriebssystem implementiert sind kann dem Rest vom Netz herzlich egal sein. Wenn der Adapter das nicht kann, dann wird das OS das auch nicht machen. Einzig Wireshark stolpert über sowas, weil der bei Offloading beispielsweise defekte Checksums bei ausgehenden Frames sieht, da die zum Zeitpunkt des Captures noch nicht berechnet sind. Ich hatte mal den Fall, in dem Checksum-Offloading bei einem Intel Desktop-Adapter auf PCs nachweislich Pakete vernichtete. Allerdings ist das schon ein halbes Jahrzehnt her.
Kandidat für Ärger in Abhängigkeit von der Grösse übertragener Pakete könnten Jumbo-Frames sein. Wenn die irgendwo eingeschaltet sind, aber nicht alle beteiligten Rechner und Switches dazu der gleichen Ansicht sind, dann gibts Ärger.
Das "mysteriöse" an der Angelegenheit nochmal kurz zusammengefasst: - auf dem "alten" Server (ebenfalls VM) ging es sowohl zum LAN hin als auch nach draussen (VPN), also kein grundsätzliches Problem - bei einem Zugriff auf den neuen Server von Aussen übers Internet (per VPN), geht es auch heute noch - es funktioniert nun nur im LAN nicht mehr Ich rätsle bereits geraume Zeit, was man wie konfigurieren muss, um das hinzukriegen :-((
Frank Esselbach schrieb: > - bei einem Zugriff auf den neuen Server von Aussen übers Internet (per > VPN), geht es auch heute noch > > - es funktioniert nun nur im LAN nicht mehr Klingt wirklich schwer nach MTU-Problem, wenn es mit Router geht, ohne aber nicht. Wobei die erwähnten Jumbo Frames auch auf ebendies hinauslaufen.
A. K. schrieb: > Klingt wirklich schwer nach MTU-Problem, wenn es mit Router geht, ohne > aber nicht. Wobei die erwähnten Jumbo Frames auch auf ebendies > hinauslaufen. Klingt nach einem Hoffnungsschimmer. Ich habe zwar selber Zugriff auf die VM von "Innen", sogar Adminrechte, aber die Einstellung für MTU und Jumboframes kann ich bei "Konfiguration" des Netzwerkadapters nicht finden. Was mir noch komisch vorkommt: Der Netzwerkadapter ist plötzlich vom Typ "Parallels Ethernet Adapter". Und die ebenfalls installierten VMWare-Tools lassen sich nicht mehr starten ... ? Sollte der Admin die VM-Umgebung gewechselt haben? Allerdings hat das dass Problem nicht gelöst ... :-((
Frank schrieb: > Sollte der Admin die VM-Umgebung gewechselt haben? Das hat er offenbar. In einer VM unter VMware gibt es keinen "Parallels Ethernet Adapter", folglich muss es sich um einen anderen Hypervisor handeln. Es wird wohl der von Parallels sein. ;-) Bisher kannte ich diesen Namen freilich nur in Zusammenhang mit Macs, was für grössere VM-Farmen eine etwas ungewöhnliche Umgebung wäre, es könnte sich aber auch um Virtuozzo handeln. Ist nicht so ganz meine Ecke, ich bin mehr in VMware zu Hause.
Schon mal ganz simpel die Einstellungen der alten mit der neuen Netzwerkkarte verglichen? j/n
oszi40 schrieb: > Schon mal ganz simpel die Einstellungen der alten mit der neuen > Netzwerkkarte verglichen? j/n Ich bin bloß der Anwendungsentwickler, dessen Anwendung NACH DEM UMZUG auf eine leistugsfähigere VM (bzw. nach der Zuteilung von mehr Resourcen, genau weiss ich das nicht) nicht mehr läuft. Ich habe keinen Zugang zur Serverkofiguration und der Admin meint, er habe Nichts damit zu tun. Ich glaube - gutes Verhältnis zum Admin hin oder her - das wird jetzt Gegenstand einer Petzmeldung an die Geschäftsleitung.
es kann auch an den Clients liegen. Wenn der Server jetzt deutlich schneller arbeitet und den Clients die Pakete zu schnell um die Ohren haut haben die evtl. damit ein Problem. Wenn man UDP für verlustfreie DÜ nutzen will dann muss man sich ein Protokoll mit Fehlersicherung dazu bauen. Wenn das nicht drin ist hat es vorher eher zufällig funktioniert. Als Workaround könnte man versuchen in der Netzwerkkarte die Anzahl der Empfangspuffer zu erhöhen, aber nicht alle Karten haben diese Einstellmöglichkeit. Und werden die Datagramme auf eine max. Grösse limitiert? Die max. Grösse bei UDP kann auf verschiedenen System unterschiedlich sein. Das hat noch nix mit Jumbos zu tun, wenn die MTU auf Default belassen wird dann werden die eh nicht genutzt. Aber wie die meisten hier schon schrieben: ein Ethernet Sniffer Log ist nötig.
JojoS schrieb: > Wenn man UDP für verlustfreie DÜ > nutzen will dann muss man sich ein Protokoll mit Fehlersicherung dazu > bauen. Wenn das nicht drin ist hat es vorher eher zufällig funktioniert. Es gibt ein ausgefeiltes Protokoll inkl. Prüfsumme. Das Problem ist vermutlich wirklich nur die Paketgröße. Wie bereits erwähnt, funktioniert es ja übers Web ... auch bei einem Bekannten mit 100 MBit-Anbindung (Kabel Deutschland). Ich habe in das Programm mal zusätzliche Protokollfunktionen eingebaut, der Abruf der Mitarbeiterliste ist ja nicht die erste und einzige Kommunikation mit dem Server. Funktioniert Alles bestens, bis zu dem Moment, wo die Liste angefordert wird. Der Server sendet sie ab, aber sie kommt nie an und das UDP-Socket ist anschiessend für jede weitere Kommunikation blockiert. Erst ein NEW macht es wieder verfügbar. Das tritt aber nur im LAN auf, nicht per Web. Erschwerend kommt hinzu, dass das ganze ca. 200 km weit weg von mir passiert und ich "nur" VPN-Zugang zu der konkreten VM habe, nicht zu deren Host.
Versuch doch "die Liste" einfach mal in mehre UDP Pakete aufzuteilen.
Läubi .. schrieb: > Versuch doch "die Liste" einfach mal in mehre UDP Pakete aufzuteilen. Ja, werde ich wohl auch zähneknirschend so machen. Aber da es ja schon mal ging (und übers Web immer noch geht) und der Admin sich so bockbeinig stellt, ärgert mich das Ganze ziemlich ...
Tolleriert das Protokoll denn das Fehlen einzelner Datagramme bzw. hast du dafür ein Resend implementiert? Eine Prüfsumme über alles reicht nicht.
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.