none
Windows Server 2012 R2 TCP Socket wird alle 6 Minuten "gelöscht" RRS feed

  • Allgemeine Diskussion

  • 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?


    Donnerstag, 11. Juni 2015 09:13

Alle Antworten

  • Hi,

    vielleicht ist der Keep-Alive-Wert auf dem System verstellt?

    http://www.consic.de/support/keepalive.htm


    Gruß

    Ben

    MCSA Windows 8 (.1) MCSA Windows Server 2012 (R2)

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Donnerstag, 11. Juni 2015 09:19
  • Hi Ben,

    danke für die rasche Antwort. KeepAliveTime war einer der ersten Timeout-Parameter, die wir in der Registry ausprobiert haben - hat leider keine Besserung gebracht.

    Lg, Hannes

    Donnerstag, 11. Juni 2015 09:54
  • Hallo needmorebuffer

    „von Windows Server 2003 nach Windows Server 2012 R2 migriert“
    Das könnte allerdings einen langen Weg. Haben Sie die ISDN selbe Karten behalten ? Oder nur den Treiber erneuert ?
    Es ist mir nicht klar ob Sie eine andere ISDN Karte probiert haben ?
    Sehen Sie etwas mit Wireshark ? Zum Beispiel, gibt es etwas wie TCP restransmission ?
    Gibt es eine Möglichkeit die Aktivität der ISDN Karte zu beobachten wie auf einem Cisco ? Vielleicht der D-Kanal wird aufgeschaltet.

    http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1917.html

    Vielen Grüße

    Nathan

    Freitag, 12. Juni 2015 09:00