ZusiDisplay bekommt keine TCP-Verbindung

[TangoLima]

Hallo zusammen,

ich würde gerne den Ebula von ZusiDisplay mit Zusi3 nutzen. Doch leider habe ich ein Problem, das ich nicht selbst lösen kann.

- Ich starte Zusi3, der interne TCP Server ist aktiv auf 127.0.0.1 und auf meiner IPv4 Adresse.
- Auf dem gleichen Rechner starte ich nun ZusiDisplay. Als einziges Modul, nutze ich den Ebula
- In Zusi3 sehe ich nun, unter Konfiguration - Netzwerk - Clients, einen Eintrag
- Nun lade ich in Zusi3 einen Fahrplan. Leider wird im ZusiDisplay nichts dargestellt.
- Sobald der Zug aufgegleist ist, erscheint im ZusiDisplay der Fehler "Keine TCP-Verbindung".

Eine Änderung der Ports, sowohl in Zusi3 als auch in ZusiDisplay, von 1436 auf 50000, 60000 oder auch dazwischen, brachte keine Besserung.
Ausschalten des lokalen Virenscanners führte immer noch zu dem o.g. Verhalten.
Ausschalten der Windows Firewall brachte auch nichts.
Das Einstellen der IPv4 Adresse, statt localhost in ZusiDisplay half leider auch nichts.
Das Ausführen der Programme als Administrator führte auch immer zum gleichen Ergebnis.

So langsam weiß ich nicht mehr weiter...
Zusi3 und ZusiDisplay laufen auf einem Rechner, mit zwei Monitoren. Auf dem Rechner ist ein aktuelles Win10 (64bit) installiert. Alle MS-Patches sind eingespielt.
Die Zusi3 Version ist 3.1.1.0, die ZusiDisplay Version ist 3.2.216.0

Ich habe mal das Log vom ZusiDisplay eingeschaltet.

Code: Alles auswählen

2016-09-14 21:30:21.9754|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() mit Zusi3 via 127.0.0.1:1436
2016-09-14 21:30:21.9754|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() erfolgreich
2016-09-14 21:30:21.9754|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Sende Zusi-HELLO
2016-09-14 21:30:21.9754|INFO|MMI.EBuLa.Tools.SuperNetwork|Starte TCP-Lesen-Thread.
2016-09-14 21:30:48.1560|ERROR|MMI.EBuLa.Tools.SuperNetwork|TCP-Verbindung ist abgebrochen. Grund: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
2016-09-14 21:30:48.1560|INFO|MMI.EBuLa.Tools.SuperNetwork|Zusi-TCP-Socket wurde von extern geschlossen. Warte 1 Sekunde...
2016-09-14 21:30:49.1582|INFO|MMI.EBuLa.Tools.SuperNetwork|Zusi-TCP-Socket wird neu aufgebaut.
2016-09-14 21:30:49.1582|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() mit Zusi3 via 127.0.0.1:1436
2016-09-14 21:30:49.1582|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() erfolgreich
2016-09-14 21:30:49.1582|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Sende Zusi-HELLO
2016-09-14 21:30:49.1582|INFO|MMI.EBuLa.Tools.SuperNetwork|Starte TCP-Lesen-Thread.
2016-09-14 21:30:49.1627|ERROR|MMI.EBuLa.Tools.SuperNetwork|TCP-Verbindung ist abgebrochen. Grund: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
2016-09-14 21:30:49.1627|INFO|MMI.EBuLa.Tools.SuperNetwork|Zusi-TCP-Socket wurde von extern geschlossen. Warte 1 Sekunde...
2016-09-14 21:30:50.1639|INFO|MMI.EBuLa.Tools.SuperNetwork|Zusi-TCP-Socket wird neu aufgebaut.
2016-09-14 21:30:50.1639|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() mit Zusi3 via 127.0.0.1:1436
2016-09-14 21:30:50.1639|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() erfolgreich
2016-09-14 21:30:50.1639|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Sende Zusi-HELLO
2016-09-14 21:30:50.1639|INFO|MMI.EBuLa.Tools.SuperNetwork|Starte TCP-Lesen-Thread.
2016-09-14 21:30:50.1639|ERROR|MMI.EBuLa.Tools.SuperNetwork|TCP-Verbindung ist abgebrochen. Grund: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
2016-09-14 21:30:50.1639|INFO|MMI.EBuLa.Tools.SuperNetwork|Zusi-TCP-Socket wurde von extern geschlossen. Warte 1 Sekunde...
2016-09-14 21:30:51.1721|INFO|MMI.EBuLa.Tools.SuperNetwork|Zusi-TCP-Socket wird neu aufgebaut.
2016-09-14 21:30:51.1721|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() mit Zusi3 via 127.0.0.1:1436
2016-09-14 21:30:51.1721|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Connect() erfolgreich
2016-09-14 21:30:51.1721|INFO|MMI.EBuLa.Tools.SuperNetwork|TCP-Socket: Sende Zusi-HELLO
2016-09-14 21:30:51.1721|INFO|MMI.EBuLa.Tools.SuperNetwork|Starte TCP-Lesen-Thread.
2016-09-14 21:30:52.1828|ERROR|MMI.EBuLa.Tools.SuperNetwork|TCP-Verbindung ist abgebrochen. Grund: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Ich hoffe, es kann mir da jemand aus der Patsche helfen.

Viele Grüße
Thomas

[Jens Haupert]

Bitte am WE nochmal ein Hinweis auf das Problem. Danke.

[F. Schn.]

Nur Info: Das ist das, was ich hier schon mal hatte: http://forum.zusi.de/viewtopic.php?p=263607#p263607" target="_blank Der Fehler kam bei mir plötzlich und verschwand genauso wieder. Du kannst ja mal testen, ob man mit meinem Adapter ( http://forum.zusi.de/viewtopic.php?f=73&t=12751" target="_blank ) irgendein Zusi-2-TCP-Programm an Zusi3 laufen lassen, zum Beispiel ZusiMeter eine stabile Verbindung hinbekommt. Bei mir war es aber so, dass alles klappte und nur ZusiDisplay Probleme gemacht hatte.

Ggf. kann ja jemand meine Beiträge hier her schieben.

Wie gesagt: Zur Lösung kann ich damals leider nicht beitragen, aber wenn der Fehler bei dir nicht auch plötzlich verschwindet, kann das vielleicht helfen, ihn zu finden.

[TangoLima]

Danke für die Info. Ich schaue mir mal die alten Beiträge an. Evtl. hilft es ja etwas weiter.

Viele Grüße
Thomas

[Gerald Hunker]

- Auf dem gleichen Rechner starte ich nun ZusiDisplay. Als einziges Modul, nutze ich den Ebula
- In Zusi3 sehe ich nun, unter Konfiguration - Netzwerk - Clients, einen Eintrag

Kommt mir irgendwie bekannt vor. Die Konfiguration "Ebula allein zuhaus" ist manchmal etwas zickig.
Folgender Workaround könnte helfen: Stelle in den Einstellungen unter "Verbindungen" auf "Master" um. Das ist zwar nicht Sinn der Sache, denn ein Ebula kann eigentlich kein Master sein. Du solltest also daran denken, die Einstellung gelegentlich wieder zurückzunehmen. Wenn du aber für den Moment nur Ebula benötigst, sollte das helfen.

Alternativ kannst du auch zuerst irgendein MFA oder Diagnose-Display starten, das sich als Master betätigt. Wenn du es nicht benötigst, schiebst du es in den Hintergrund. Wenn du dann Ebula startest, sollte dieses den Master finden und einwandfrei funktionieren.

Grüße, Gerald

[TangoLima]

Hallo Gerald,

leider bringt dieser Workaround auch keine Besserung. Egal Welches Modul ich auswähle, es blinkt in der Win.Taskleiste immer rot, bzw. zeigt nichts an, oder wie beim FIS, gibt keinen Ton von sich.
Hatte jetzt auch schon mal Zusi3 komplett neu installiert..

VG
Thomas

[Gerald Hunker]

Hallo Thomas,

dann tippe ich ganz stark auf Firewall und/oder Virenschutz.
Du hattest ja oben geschrieben, dass die Verbindung initial einmal zu Stande kommt - richtig? ZD zeigt sich in Zusi in der Rubrik Netzwerk - richtig?
Wenn die Verbindung dann kurze Zeit später wieder abbricht, dann hat "jemand" die gekappt. Dafür kommen auf einem PC nicht viele Instanzen in Frage.
Ich würde erstmal in dieser Richtung forschen - und bloß nicht alle Naselang Zusi neu installieren, es gibt schönere Hobbies

Viel Erfolg!

Gerald

[TangoLima]

Hi,

ich habe jetzt alles mögliche mit meiner Firewall am PC und dem Virenscanner angestellt. Zuletzt war der Virenscanner deinstalliert und die Win. Firewall deaktiviert. Hat leider alles nichts gebracht.
Testhalber habe ich mal meinen Firmen-Laptop, auf dem ein Win7 läuft, genommen und dort Zusi3 komplett installiert. Dort funktioniert alles auf Anhieb.
Dann, auf dem Laptop nur ZD gestartet und auf dem PC Zusi3. Genau das gleiche Verhalten, wie wenn beide Programme auf dem PC laufen. Sobald der Zug aufgegleist ist, verliert ZD die TCP Verbindung.

Witziger Weise funktioniert es anders rum. Auf dem Laptop Zusi3 gestartet und auf dem PC ZD. Das klappt einwandfrei, ist nur leider keine dauerhafte Lösung.
Mir scheint, irgendwas haut da bei Zusi dazwischen, was dazu führt, das ZD die Verbindung verliert, Da ich jetzt wenig Lust verspüre, mein Win10 neu aufzusetzen, werde ich wohl erstmal damit zurecht kommen müssen.

Trotzdem vielen Dank für die Vorschläge.
VG
Thomas

[F. Schn.]

Wie gesagt: Ich hatte das ja auch, und da hatte ich auch einiges probiert. Der Fehler schien etwas mit Zusi zu tun haben, aber er muss dennoch noch auf Zusi-Display-Seite liegen, z.B. funktioniert mein Converter ja Problemlos. Sehr hilfreich wäre es vermutlich, wenn Jens den Aufruf-Stack der Exception hätte, den hat er allerdings nicht ins Log aufgenommen. Dann wird vermutlich auch klarer, warum der Fehler nicht durchgehend auftritt.

[Gerald Hunker]

Dann, auf dem Laptop nur ZD gestartet und auf dem PC Zusi3. Genau das gleiche Verhalten, wie wenn beide Programme auf dem PC laufen. Sobald der Zug aufgegleist ist, verliert ZD die TCP Verbindung.

OK, dann mal eine andere Idee: Vielleicht sitzt irgendein Programm - und sei es nur für einige Sekunden - auf dem Port 1436?

Gleich nach dem Start des PC und VOR dem Start von Zusi oder ZD öffne eine Kommandozeile (Start -> Ausführen -> cmd) und gib dort folgendes ein: netstat -a | more
Du siehst eine Auflistung nach dem Schema IP-Adresse:Port Hostname:Port Status
Schau dir einmal die Portnummern an, die dort angezeigt werden. (Seitenweise blättern mit Leertaste).
Ist dort 1436 schon belegt ("listening" oder "waiting" oder so....)?
Dann weißt du zwar immer noch nicht, wer den Port belegt. Das herauszufinden, ist gar nicht so einfach, aber dann hättest du jedenfalls eine Erklärung.
UND:
Kontrolliere bitte vorab noch einmal, welche Ports in Zusi und in ZusiDisplay eingestellt sind. Ggf. wieder auf "Default" stellen, also 1436 für Zusi3, 1435 für Zusi2.
Als Workaround könntest du den Port auch einfach mal ändern und schauen, ob's dann besser funktioniert.

Gruß, Gerald

[Holger Maaß]

Es tut mir leid, es so hart sagen zu müssen:

Aus der obigen Log-Datei:

Code: Alles auswählen

...
2016-09-14 21:30:50.1639|ERROR|MMI.EBuLa.Tools.SuperNetwork|TCP-Verbindung ist abgebrochen. Grund: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
...

Das ist ein Programmierfehler, den nur Jens gerade biegen kann!

Holger

[Jens Haupert]

Eas ist ein Programmierfehler, den nur Jens gerade biegen kann!

Naja, es ist eher ein externen Problem, welches sich in der Zusi-ZD-Verbindung niederschlägt. Der Grund für die Fehlermeldung ist, dass der Socket abraucht an einem Punkt an dem das nicht erwartet wird bzw. auch keinen Sinn macht. Ich kann das abfangen, es kommt aber trotzdem keine Verbindung zu stande. Offen bleibt die Ursache.

Grüße
Jens

[Holger Maaß]

Hi Jens,

ich habe in der iPad-Version mit einem ähnlichen Problem zu tun gehabt. Prüfe doch bitte mal, ob dein Code mit fragmentierten Datenpaketen klar kommt. Das war bei mir der Grund: manchmal - und eben nur manchmal - kommen Pakete vom Zusi fragmentiert an. Darüber ist mein Code gestolpert. Ich benutze daher eine doppelte Pufferung. Auf dem Listener ankommende Daten werden sofort in einen 2. Puffer geschrieben und erst wenn das Paket vollständig ist, zum Auswerten geschickt.

Bei .net könnte der Grund auch der Garbage-Collector sein. Wann dieser zuschlägt, ist ja nicht vorhersehbar. Bei einem Rechner, der nicht allzu üppig mit RAM ausgestattet ist und vielleicht sogar noch swappen muss, könnte die Unterbrechung durch den Garbage-Collector ein ernsthaftes Problem darstellen. Wenn das Lesen der Daten in einem eigenen Thread passiert (wovon ich mal ausgehe), könntest du den Einlesevorgang in eine CriticalSection packen, um eine Unterbrechung durch den GC zu verhindern.

Ein weiteres (aber nicht wirklich zu empfehlendes Mittel) wäre die Änderung der Threadpriorität. Allerdings macht die Windows-Threadverwaltung ihre Sache sehr gut und man kann sie durch manuelles Eingreifen eigentlich nur verschlimmbessern .

3. Änderung, weil mir ist noch was eingefallen:
Eine Socket-Verbindung zwischen 2 Programmen auf ein und demselben Rechner ist ohnehin nicht die beste Lösung. Es wird ja tatsächlich der TCP-Stack für die Kommunikation genutzt. Wenn nun TangoLima so'n, Rechner erwischt hat, bei dem die Netzwerkkommunikation statt der Hardware dem Treiber übergeholfen wird (z.B. manche Broadcom und Realtek-Chips), dann, Houston, haben wir ein Problem ...

Gruß Holger.

[F. Schn.]

Hallo Jens,

ich wäre mir nicht sicher, ob es tatsächlich ein geschlossener Socket ist. Es könnte ja auch sein, dass du versehentlich Methoden eines null-Strings aufrufst oder sonnst irgendwas, was man eben nicht sofort erkennt. Auch warum ein geschlossener Socket null wird und nicht eben erst mal geschlossen, aber noch da (es würden dann andere Ausnahmen geworfen) ist mir nicht so klar.


@holmexx:

ich habe in der iPad-Version mit einem ähnlichen Problem zu tun gehabt. Prüfe doch bitte mal, ob dein Code mit fragmentierten Datenpaketen klar kommt. Das war bei mir der Grund: manchmal - und eben nur manchmal - kommen Pakete vom Zusi fragmentiert an. Darüber ist mein Code gestolpert. Ich benutze daher eine doppelte Pufferung. Auf dem Listener ankommende Daten werden sofort in einen 2. Puffer geschrieben und erst wenn das Paket vollständig ist, zum Auswerten geschickt.

Die Fragmentierungsfehler traten bei mir (bei der Entwicklung der TCP-DLL von mir und Andreas) immer Spontan auf, nie so, dass es sich bei absolut jedem Verbindungsversuch identisch verhielt. Keine Ahnung, wie das bei Jens ist.

Eine Socket-Verbindung zwischen 2 Programmen auf ein und demselben Rechner ist ohnehin nicht die beste Lösung.

Das ist im Prinzip das Problem, was Richard mit Signalsoft bei Routern hat, wenn sich der Router mit der eigenen WAN-IP verbinden soll? Nur: Auf dem eigenen Rechner habe ich mit Loopback noch nie Probleme gehabt und auch hier wäre die Frage, warum das bei dem Zusi-2-TCP-Server + ZusiMeter + Converter Zusi 3->2 mit Insgesammt 3 TCP-Verbindungen auf dem lokalen Rechner noch nie Probleme gemacht hat, während es bei ZD zu 100% reproduzierbar war (bis es überhaupt nicht mehr auftrat)

Wie gesagt: Wenn bei mir oder Andreas bei unserer TCP-DLL ein solcher Fehler auftauchen würde, dann wäre für mich die alleinige Nullreference-Log-Meldung ohne Stack zu wenig, um das korrekt analysieren zu können, wo da überhaupt etwas schief geht.

Gruß
F. Schn.

[Holger Maaß]

Hi F.Schn.,

ich las deinen Post und nun siehst du mich nicken (guckssst_du). Ohne den Quellcode sind wir halt alle zum klugscheißen verdammt . Jetzt ist es Jens, der mit dem ganzen Quatsch allein im Regen steht ...

Wenn ich noch mal (einmal noch) klugscheißen darf: ich würde die Ursache auch eher nicht extern suchen.

Holger

[florian1011]

Gibt es schon eine Lösung?
Tante Edith sagt:
Auch ich habe dieses Problem.
System:
Win 10 Pro x64 inkl. aller Updates.

[F. Schn.]

Gibt es schon eine Lösung?

So wie ich das interpretiere sucht Jens nach wie vor nach Leuten, die überhaupt das Problem haben. TangoLima scheint derzeit der einzige zu sein, bei dem es aktuell noch da ist, bei mir ist es wie gesagt plötzlich verschwunden und nie wieder aufgetaucht.

[TangoLima]

Hi,
zwischenzeitlich hat sich an dem genannten Verhalten nichts geändert. Leider hat sich das Problem nicht von alleine gelöst und besteht somit immer noch.

Viele Grüße

[TangoLima]

Hallo,

dank eines netten Tipps habe ich jetzt Verbindung zwischen Zusi3 und ZD.
Dazu habe ich Zusi deinstalliert und dann via regedit.exe alle Einträge, die mit Zusi zu tun haben, aus der Registry entfernt. Anschließend, alles vom USB Stick neu installiert. (vollständige Installation).
Das Update auf die aktuelle Version ausgeführt. ZD wurde mit Administratorberechtigungen einmal gestartet und hat sich auch gleich erfolgreich beendet.

Zusi3 und ZD gestartet, TCP Server gestartet und die Verbindung klappte sofort, mit den Standard Einstellungen. Nur den Buchfahrplan musste ich noch manuell laden, was aber, wenn ich das richtig in Erinnerung habe, eine Einstellungsoption in ZD ist.

Vielen Dank für die Untersützung!

VG
Thomas

[F. Schn.]

Tja, dann haben wir nur noch Florian, bei dem wir auch wirklich eine Lösung finden können.

@florian: Kannst du mal mit dem regedit.exe alle Registry-Schlüssel von Zusi exportieren? Vielleicht bekommen wir dann eine Repro hin.