[needmorecoffee]

Hallo!

Wir haben für Kunden-Software das Hosting von Windows Server 2003 nach Windows Server 2012 R2 migriert. Dabei wurde nur die Hardware (neuer HP ProLiant Server), das Betriebssystem und die ISDN Karte samt Treiber getauscht/erneuert, die eigentliche Software sollte weitestgehend unverändert bleiben. Diese Kundensoftware besteht technisch aus einer C++ Applikation, die einen Charakter String aus einem ISDN D-Kanal entgegennimmt, und über einen TCP Socket (auf localhost Port 30000) an eine JAVA Applikation weiterreicht, die die Daten weiterverarbeitet. Ein solches Datenpaket kommt etwa alle 30 Sekunden, ist knapp 30 Byte lang und ist vom Format immer gleich. Das Problem: Nach etwa 6 Minuten, der Intervall ist immer gleich, "verstirbt" der Socket. Nachdem beide Applikationen den Ausfall in die Log-Files schreiben und den Socket löschen und neu aufmachen, läuft wieder alles wunderbar für weitere 6 Minuten.

Die C++ App meldet mir aus der send() Funktion des Sockets einen WSA Error 10054 "Connection closed by peer", die JAVA app meldet auf dem socket.read() ein "software caused connection abort: recv failed"

Diese Kunden-Software ist seit Jahren auf Windows Server 2003 und einem Dell Server an 9 Standorten im Einsatz, und zeigt keinerlei Probleme.

Was schon gemacht wurde und keine Besserung gezeigt hat:

- Firewall komplett dektivieren
- andere Ports verwenden (30001, 30500, 16000, 997)
- eigene IP statt localhost verwenden (10.16.58.30)
- diverse TCP Timeouts, die wir im Web finden konnten, in 'Parameters' in der Registry eintragen
- JAVA auf die Letztversion Updaten
- alle empfohlenen Updates für Windows Server 2012 einspielen
- beide Applikation bis auf den Socket reduzieren, um auszuschließen, daß die eigene Software ein Problem verursacht
- statt der ISDN Botschaft eine immer gleiche Standard-Botschaft über den Socket schicken, um auszuschließen, daß eine verunstaltete Botschaft den Socket beeinträchtigt
- Kontrolle der mitgeschickten Botschaftslängen, um eine 0-Länge auszuschließen
- alle Buffer auf der Sende- und Empfangsseite kontrolliert, um Bufferüberläufe auszuschließen
- Kontrolle, ob irgendeine andere Software auf dem Server einen "unserer" Ports verwendet

Einzig, wo das Problem nicht auftritt ist, wenn wir von extern über Telnet die Botschaften manuell, oder in verschiedenen Intervallen über ein Bash Script an den Port des Servers und die JAVA Applikation senden.

Vermutung: Irgendein Timeout oder ein Kontrollmechanismus auf Betriebssystem-Ebene löscht den Socket. Irgendwelche Ideen, was das sein könnte?

Dieser Beitrag wurde von needmorecoffee bearbeitet: 11. Juni 2015 - 12:39

[der dom]

Ist zwar länger her, aber wenn das Problem noch besteht....vielleicht hilft es vor Ablauf der 30 Sek. mal einen Stream zu senden, der die Verbindung aufrecht erhält. 1 Byte oder so das auf der Gegenseite direkt verworfen wird.

Ich kenne solche Probleme von anderen Programmen im Zusammenhang mit Fremdsystemen. Da kackt ganz gerne mal der gesamte Rechner mit BSOD ab und es ist nicht wirklich nachvollziehbar woran es liegt.

Das senden eines Extrabytes zur Zeit 5:58 wäre ein Versuch wert. Wie läuft denn die Kommunikation? Rein lokales Netz oder ist es im VPN oder ggf. V-Lan?

Bei VPN kann es sein, dass der Tunnel kurz blockiert. Bei V-Lan kann es ein Packagelost sein. Wobei ich bei V-Lan ohnehin Gänsehaut bekomme.

Was JAVA angeht - vorsichtig sein. Nicht alles was neu ist, ist immer gut. Es gibt hier zig Programme die nicht mehr laufen nur weil die neuste Runtime installiert wurde. Es kann also sein, dass ihr mit der neusten Version die Situation verschlimmbessert.

Gruß,
Dom