[erledigt] 3.3.7.0 - TCP-Client verbindet sich nicht mehr

[Thomas B]

Guten morgen,
ich musste gestern nach dem Update auf Version 3.3.7.0 feststellen, dass sich mein Fahrpult-Client nicht mehr mit Zusi verbinden kann, da sich anscheinend etwas am Protokoll geändert hat. Genauer gesagt am Knoten ACK_NEEDED_DATA.

So sah es bisher aus:

Code: Alles auswählen

Zusi 3 TCP data
    Node, id = 0x2 [Client-Anwendung 02 (Fahrpult)]
        Node, id = 0x4 [Befehl ACK_NEEDED_DATA]
            Attribute, id = 0x1 [Akzeptiert], value: byte = 0 [Befehl akzeptiert] [00]

So sieht es jetzt aus:

Code: Alles auswählen

Zusi 3 TCP data
    Node, id = 0x4

Ist das jetzt ein Bug / soll dass so sein / oder muss ich etwas am NEEDED_DATA Knoten ändern? Der Doku kann ich keine Änderung entnehmen, ich bitte um Hilfe.

[F. Schn.]

Kann ich so bestätigen, es werden keine Attribute mehr als Reaktion auf NEEDED_DATA gesendet.
Ich kann auch nicht erkennen, wo in Carstens TCP-Demo-Code der Empfang von ACK_NEEDED_DATA kontrolliert wird, aber vielleicht habe ich das nur noch nicht gefunden.

[Carsten Hölscher]

ACK_Hello schickt als weiteres Paket eine Versionsnummer. Wenn man die nicht erwartet und nicht sauber programmiret hat, bleibt man da hängen.

Carsten

[Johannes]

Ich kann die Meldung nachvollziehen. ACK_HELLO behandle ich korrekt und bekomme trotzdem Unsinn. Die mitgelieferte TCPDemoOutput.exe schafft es auch nicht, sich zu verbinden. Edit: Diee Version aus Paket 104 kann eine Verbindung aufbauen, aber nur, weil sie anders als die Vorversion das Paket ACK_NEEDED_DATA nicht liest und nur schaut, ob Zusi irgendwas sendet.

[Thomas B]

ACK_Hello schickt als weiteres Paket eine Versionsnummer. Wenn man die nicht erwartet und nicht sauber programmiret hat, bleibt man da hängen.

Carsten

Hallo Carsten,
mein TCP-Client empfängt immer grundsätzlich alles und bildet dann eine Baum-Struktur zum Abfragen von Knoten\Unterknoten\Attributen. Von daher ist er relativ tolerant, was Änderungen im Protokoll angeht- solange die Hierarchie stimmt.
Aber: bisher habe ich immer noch als zusätzlichen Schritt nach ACK_HELLO auf den Knoten 0x04 ACK_NEEDED_DATA gewartet. Der ist aber jetzt plötzlich nicht mehr Unterknoten von Id 0x02 (Siehe Hex-Dump oben). Ich hab die Abfrage jetzt erst mal rausgenommen, so geht es auch. Ist aber nicht im Sinne des Erfinders denke ich.

[F. Schn.]

Das Problem ist nicht ACK_HELLO (und auch nicht, dass dort irgendwas zu viel ist) sondern ACK_NEED_DATA. Das Paket ACK_NEED_DATA fehlt einfach komplett. Das Paket ACK_NEED_DATA sollte aus den Knoten 0x0002, 0x0004 und dem Attribut 0x0001 bestehen, wie es in der Doku in 11.3.3.2 unmissverständlich beschrieben ist. Aber es fehlt einfach. Stattdessen kommt ein einzelner Leerer Knoten, der den Spezifikationen nach 11.3.3.2 nicht genügt.

Wenn man gar nicht erst auswertet, ob ACK_NEED_DATA gesendet wurde, ist eine Verbindung trotzdem möglich.

[Carsten Hölscher]

OK, danke für die Meldung - schau ich mir morgen an.

Carsten

[Carsten Hölscher]

Dann bitte mal mit der beta von heute testen.

Carsten

[Holger Maaß]

Das ist leider immer noch falsch. Jetzt wird gesendet

Code: Alles auswählen

Knoten #4
  Attribut #1, Wert 0

Richtig wäre aber

Code: Alles auswählen

Knoten #2
  Knoten #4
    Attribut 1, Wert 0

Gruß
Holger

[Thomas B]

Ich kann mich Holger nur anschließen. Der Knoten enthält jetzt zwar wieder das Bestätigungs-Byte, ist aber immer noch falsch eingeordnet.

[Carsten Hölscher]

Jau sorry, neue Version (nicht groß getestet).

Carsten

[F. Schn.]

Sieht wieder korrekt aus.

[Thomas B]

Jepp, es ist wieder so wie's sein soll, danke für die Unterstützung