Netzwerkunterbruch

Product :4D - 4D Server
OS : Windows
V17.4

Bei unserem automatisierten Datenabfrage- und Publikationssystem welches wir kürzlich von v14.6 auf v17.3 und nun auf v17.4 upgegradet haben erhalten wir immer wieder die Meldung “Die Verbindung wurde wegen eines Netzwerkfehlers unterbrochen oder konnte nicht hergestellt werden”.
Das System läuft in einer grösseren Netzwerkumgebung unter Windows und besteht aus automatisierten Clients und Benutzer-Clients (zum Daten bearbeiten). Da es ein automatisiertes System ist, muss es zwingend rund um die Uhr zuverlässig funktionieren. Erscheint diese Meldung, bleibt das System hängen und muss durch einen Benutzereingriff wieder zum Laufen gebracht werden. Weil es sich um sensible Daten für die Behörden handelt, haben wir eine zweite Supervisor-Applikation gebaut welche sowohl den Server wie auch die Clients überwacht und in einem solchen Fall automatisch neu startet. Der Supervisor macht in regelmässigen Abständen eine TCP-IP Anfrage an die Hauptapplikation um zu schauen ob diese noch “lebt”. Die Clients machen bei einer solchen Anfrage des Supervisors ein Query um sicherzustellen, dass die Verbindung zum Server noch vorhanden ist.
Nun kommt es aber vor, dass ein Client mit der Meldung wegen Netzwerkunterbruch zum stehen kommt, dem Supervisor aber eine trotzdem seine Anfrage beantwortet. Deshalb wird der Client nicht automatisch neu gestartet.
Hier nun meine Frage: Unter welchen Umständen erscheint die Meldung auf dem Client? Kann es sein, dass andere Prozesse auf dem Client trotzdem laufen und sogar die Verbindung zum Server noch steht? Kann ich diese Meldung automatisiert beenden?

seitens 4D haben wir in der Client-/Serverumgebung alle uns bekannten Netzwerkprobleme behoben. Wir kennen die vorliegende Topologie bei diesem Kunden nicht und Sie schreiben auch nicht, ob Sie die alte Netzwerkschicht (legacy) oder die neue Netzwerkschicht verwenden. Sollten Sie die neue Netzwerkschicht verwenden, wäre ein einfacher Test, einfach mal auf die alte netzwerkschicht zurückzuwechseln. Das ist ab v17 möglich. Ist das Problem weg, kann man in Ruhe weiter suchen.

Ab v18 konnten wir nach Wegfall von 32 bit konnten wir etliche low Level Libraries aktualisieren, vieles auf neuere APIs umstellen. Auch das könnte Abhilfe bringen.

Gibt es im Netzwerk einen “intelligenten” oder “defekten” Router/Gateway, kann es zu Problemen kommen die vorher nicht da waren. “Intelligent”: oh, da ist ein Socket offen, da lief schon einige Sekunden nichts mehr darüber, den machen wir mal zu. Bumm, Netzwerkfehler sobald der Anwender das Fenster wieder nach vorne holt und etwas macht. Abhilfe: wir schließen Sockets nach 20 Sekunden Idle automatisch und vermerken das im Diagnostik-Log. “Defekt”: oh, da werden ständig Sockets auf und zu gemacht und das von hunderten von Sockets, das schaffe ich nicht, da lass ich einzelne Anfragen aus.

Ob damit dann erst mal behoben oder nicht, weiter kommen wir hier sicher nur mit entsprechenden Logs weiter. Wir benötigen die Info-Reports vollständig, nicht nur Auszüge. Wir benötigen Diagnostik-Log vom Server und 2-3 betroffenen Clients. Dazu die Uhrzeit (möglichst genau), wann Fehler aufgetreten sind. Das Server Log zeigt uns ob zur gleichen Zeit von mehreren Clients Fehler kamen, die Client-Logs zeigen uns wie der Client die Sache sieht, im Vergleich zum Server.

Diese bitte dann dem für Sie zuständigen Support der Firma Ajar in der Schweiz zur Auswertung zukommen lassen.

Vielen Dank für das rasche Feedback. Wir verwenden die neue Netzwerkschicht, mit der Legacy-Schicht hab ich’s bis jetzt noch nicht versucht. Wir haben jedoch das Idle Connection Timeout relativ tief eingestellt damit Router nicht dazwischen funken sollten.
Gibt es eine zuverlässige Möglichkeit festzustellen, ob sich ein Client in einem “blockierten” Modus (sprich er wartet auf eine User-Aktion) befindet?

ich denke nicht, daß in diesem Fall ein eigener On Error Call anspricht. Wäre aber auch nicht der Weg, dem Problem auf die Spur zu kommen.