needmorecoffee 0 Geschrieben 11. Juni 2015 Melden Teilen Geschrieben 11. Juni 2015 (bearbeitet) 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 verwendetEinzig, 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? bearbeitet 11. Juni 2015 von needmorecoffee Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.