Frage: Warum nutzt KNX UDP und nicht TCP?

[tanzbaer]

Hi,

mich interessiert die Frage, warum die KNX/IP Schnittstelle über UDP und nicht über TCP abgebildet wurde. Im knxd Strang habe ich gesehen, dass da auf dem Applikationslayer retransmit und acks eingebaut sind. Dann ist der Vorteil von UDP weg und ich kann besser gleich tcp nehmen, da bekomme ich das umsonst mit.

Grund für die Neugier ist

1. Neugier ;-)
2. Frust. Ich habe nämlich nicht gedacht, dass eine wireless Verbindung die KNX Datenübertragung so instabil macht, dass Programmieren von Bewegungsmeldern 40 Minuten dauert und dann doch fehlschlägt. Für ein paar Byte.... ;-( Inzwischen bin ich klüger. Und mir ziemlich sicher, dass dieses Verhalten durch die Wahl von UDP statt TCP begründet ist.

[GLT]

Deine "Probleme" kann ich so nicht ganz nachvollziehen - ich programmiere viel über WLAN und habe keine signifikanten "Störungen" gegenüber anderen Buszugriffen. Wenns Probleme gibt, hat das Ursachen wie allg. hohe Buslast u/o andere Ungereimtheiten; kann auch mal Problemgeräte geben.

Da Befehlstelegramme "ungerichtet" verbreitet werden, kann man sich das Handshake sparen.

[tanzbaer]

Deine "Probleme" kann ich so nicht ganz nachvollziehen - ich programmiere viel über WLAN und habe keine signifikanten "Störungen" gegenüber anderen Buszugriffen. Wenns Probleme gibt, hat das Ursachen wie allg. hohe Buslast u/o andere Ungereimtheiten; kann auch mal Problemgeräte geben.

Ich scheine aber nicht der einzige zu sein, der das Problem hat, dass es mit Kabel super geht, über wifi aber nicht. Im gleichen Netz. Mein Verständnis der Programmierung ist, dass die ETS einen Haufen KNX Pakete rausschiebt, jedes wird in ein UDP Paket gepackt, per Kabel und/oder Luft an den IP-Router geschickt, der packt das aus und jagt es auf den TP-Bus.

Ich hatte knapp 10 Geräte am Bus als die Probleme richtig losgingen. Buslast war null. Nur sehr wenige Gruppenadressen und die werden nur aktiviert bei Taster/PM ein oder aus. Bei der Programmierung war die Buslast mit Sicherheit 0.

Trotzdem macht der Transport durch die Luft massiv Probleme und per Kabel gehts. Ich kann mir nur vorstellen, dass Luft bei mir mehr packet loss erzeugt, ein anderes Timing beim Übertragen hat oder sich die squence der Pakete ändert.

Bei den ersten beiden sollte das System bei vernünftiger Spezifikation eigentlich robust genug sein um davon nicht betroffen zu sein. Bezüglich der Sequence habe ich keine Ahnung ob bei der Programmierung die KNX Pakete eine Reihenfolge einhalten müssen.

Da Befehlstelegramme "ungerichtet" verbreitet werden, kann man sich das Handshake sparen.

Ja, aber die Vorteile werden doch mit jedem Feature weniger, dass Du bei TCP umsonst bekommst, für die die KNX Spezifikation aber einen TCP-Feature Nachbau auf dem Applikationlayer oberhalb von UDP erzwingt.

[tbi]

Das ist schon eine gute Frage, die auch eine Antwort hat.

Hallo Tanzbaer,

Hi,

mich interessiert die Frage, warum die KNX/IP Schnittstelle über UDP und nicht über TCP abgebildet wurde. Im knxd Strang habe ich gesehen, dass da auf dem Applikationslayer retransmit und acks eingebaut sind. Dann ist der Vorteil von UDP weg und ich kann besser gleich tcp nehmen, da bekomme ich das umsonst mit.

Deine Frage läßt sich leicht beantworten. Weil IP Routing auf der IP Seite viele KNX IP-Router gleichzeitig verbinden muß, ist es nötig ein Punkt -> Multipunkt Protokoll zu verwenden.

Das ist wie bei IP-TV, nur ist da der Sender fest. Bei KNX kann jeder der Sender zu den "Vielen" sein. Also IGMP ist hier das Protokoll.

Nun ist leicht verständlich, dass man nicht weiß wie viele nun die Empfänger sind, und dass man das dann auch nicht kontrollieren kann. Also hat man IGMP so spezifiziert, dass in der Protokollschicht darunter UDP zum Einsatz kommt. Das ist für ein Punkt zu Multipunkt Protokoll genau richtig.

Grund für die Neugier ist

1. Neugier ;-)
2. Frust. Ich habe nämlich nicht gedacht, dass eine wireless Verbindung die KNX Datenübertragung so instabil macht, dass Programmieren von Bewegungsmeldern 40 Minuten dauert und dann doch fehlschlägt. Für ein paar Byte.... ;-( Inzwischen bin ich klüger. Und mir ziemlich sicher, dass dieses Verhalten durch die Wahl von UDP statt TCP begründet ist.

Nun kann KNX beides:

• Punkt zu Punkt Verbindung mit der KNX Spezifkation "IP-Tunneling"
• und Punkt zu Multipunkt mit "IP-Routing".

Nun must Du selbst mal nachschauen was Deine Schnittstelle unterstützt.

In der regel ist es aber so, dass KNX IP-Router nebenbei auch das "IP-Tunneling" verwenden, was dann auch über TCP geht und damit eine Sicherungsschicht besitzt. Hier wird also kontrolliert, ob eine Packet auch angekommen ist.

Sie kann aber auch schon besetzt sein! Wird die IP-Schnittstelle verwendet ist sie belegt. Manche IP-Router habe desshalb mehrere IP-Tunneling Schnittstellen an Board.

Wenn Du nun programmierst, kannst Du in der ETS Schnittstelle wählen über welchen Protokoll du programmierst.

Da solltest Du immer "IP-Tunneling" wählen, weil eben "gesichert"

Alles klar ?

Dann sollte die Programmierung besser laufen

Gruß Tbi

[tbi]

Mal ganz einfach zum Merken:
Über WLAN macht man NIE KNX IP-Routing.

Wer IP-TV über WLAN (also über Funk) macht, hat da ein sehr gutes Buffer Management und ggf. wird so etwas wie "Retransmission" verwendet. Das sind dann aber schon Tricks speziell für Anwendungen wie IP-TV.

Gruß Tbi

[tanzbaer]

Mal ganz einfach zum Merken:
Über WLAN macht man NIE KNX IP-Routing.

Wer IP-TV über WLAN (also über Funk) macht, hat da ein sehr gutes Buffer Management und ggf. wird so etwas wie "Retransmission" verwendet. Das sind dann aber schon Tricks speziell für Anwendungen wie IP-TV.

Gruß Tbi

Ich frag hier schonmal nach, bevor ich mich an die lange Antwort mache.

Nicht machen habe ich durch reinforcement learning bereits verstanden.

Warum aber nicht. UDP wird in IP gepackt, IP dann in ethernet oder (wie auch immer das Protokoll bei WLAN heisst), dann gesendet, auf der anderen Seite entsteht erst wieder das IP Paket, dann das UDP Paket. Ob ethernet oder WLAN ist doch völlig transparent. Warum verhält sich Wifi dann anders? Da hab ich noch nen Knoten.

[tbi]

UDP ist Fire und forget. Wenn ein UDP Packet geschickt wird, kommt es an oder nicht. Der Sender kriegt davon nie was mit, ob es angekommen ist.

Bei TCP ist das anders, geht hier ein Packet verloren, wird es nochmal geschickt. Also hier wird kontrolliert, das sind also immer "Einschreiben".

Schau mal im Wikipedia nach, da wird es noch exakter beschrieben.

Gruß Tbi

[tanzbaer]

Deine Frage läßt sich leicht beantworten. Weil IP Routing auf der IP Seite viele KNX IP-Router gleichzeitig verbinden muß, ist es nötig ein Punkt -> Multipunkt Protokoll zu verwenden.

Nun ist leicht verständlich, dass man nicht weiß wie viele nun die Empfänger sind, und dass man das dann auch nicht kontrollieren kann. Also hat man IGMP so spezifiziert, dass in der Protokollschicht darunter UDP zum Einsatz kommt. Das ist für ein Punkt zu Multipunkt Protokoll genau richtig.

Ok, der Knoten ist gerade geplatzt. (Hoffe ich). Mit eigenen Worten:

KNX-IP spezifiziert generell die Kommunikation über IP, nicht nur die Strecke bis zum Router. D.h. in den meisten Projekten habe ich deshalb meist mit der Kommunikation zum Router einen 1zu1 Sonderfall.

Würde ich z.B. IP fähige Taster und Aktoren einsetzen, dann würde jeder über ethernet an einem switch hängen, aber die anderen Teilnehmer nicht kennen. Über multicast wird dann mit dem IGMP Protokoll eine Gruppe mit allen Teilnehmern gebildet und per multicast jedes Telegramm an alle gesendet. Und Multicast geht nunmal nur UDP, da nicht point2point.

Würde man tcp nutzen wollen, dann würde das zwangsläufig zu point2point Verbindungen führen und damit wäre das Grundkonzept von KNX der unabhängigen Teilnehmer mit einem Mal über den Haufen geworfen.

In der regel ist es aber so, dass KNX IP-Router nebenbei auch das "IP-Tunneling" verwenden, was dann auch über TCP geht und damit eine Sicherungsschicht besitzt. Hier wird also kontrolliert, ob eine Packet auch angekommen ist.

Bist Du dir mit TCP sicher? Ich hätte jetzt aus dem Bauch heraus vermutet, dass das auch mit UDP läuft. Der Unterschied zwischen 1-many oder 1-1 liegt ja auf der IP Ebene und drunter und im Routing, aber nicht im Layer drüber.

Wenn Du nun programmierst, kannst Du in der ETS Schnittstelle wählen über welchen Protokoll du programmierst.

Das würde meine Probleme nur erklären, wenn WIFI/LAN switchen auch die Art der Verbindung zum Router mitswitched. Oder ich eine andere auswähle, bin mir aber ziemlich sicher das nicht getan zu haben.

Da solltest Du immer "IP-Tunneling" wählen, weil eben "gesichert"

Zum Verständnis. Multicast in der ETRS ist dieses grüne verschwommene Symbol und IP-Tunneling das T-Stück?

[MarkusS]

Es geht nur sekundär um UDP oder TCP sondern in erster Linie um IP Multicast - speziell in Verbindung mit WLAN.

Normalerweise funktioniert KNXnet/IP Routing über WLAN problemlos - zumindest solange im WLAN lediglich der Client mit der ETS ist und mit einem Router KNX-IP-Router auf der Kupferseite reden will. Wenn diese Konstellation bei Dir rumpelt hast Du irgendeinen Fehler im WLAN.

KNXnet/IP kann aber im WLAN leicht eklig werden wenn im WLAN mehrere Multicast-Teilnehmer sitzen - bislang dürfte diese Konstellation sehr selten sein. Gira bastelt gerade an den Gira KNX-IP-Router eine Sonderlocke ran damit der genau diesen Fall abdecken kann, Hintergrund ist das G1 welches auch KNXnet/IP sprechen soll und von dem es mehrere in einem WLAN geben könnte - immer unter der Annahme dass es ein "schlechtes" WLAN ist welches mit Multicast eben Probleme hat.

[tanzbaer]

UDP ist Fire und forget. Wenn ein UDP Packet geschickt wird, kommt es an oder nicht. Der Sender kriegt davon nie was mit, ob es angekommen ist.

Sorry, hab das falsche Wort in die Tasten gehauen. Ich wollte verstehen, warum UDP über wifi anscheinend schlechter geht als über Kabel.

In TCP/IP und UDP bin ich aus der Vergangenheit noch recht gut mit Wissen ausgestattet, aber das war vor der Zeit von multicast und wifi.

[tanzbaer]

Es geht nur sekundär um UDP oder TCP sondern in erster Linie um IP Multicast - speziell in Verbindung mit WLAN.

Das hat inzwischen geklickt hier. ;-)

KNXnet/IP kann aber im WLAN leicht eklig werden wenn im WLAN mehrere Multicast-Teilnehmer sitzen - bislang dürfte diese Konstellation sehr selten sein. Gira bastelt gerade an den Gira KNX-IP-Router eine Sonderlocke ran damit der genau diesen Fall abdecken kann, Hintergrund ist das G1 welches auch KNXnet/IP sprechen soll und von dem es mehrere in einem WLAN geben könnte - immer unter der Annahme dass es ein "schlechtes" WLAN ist welches mit Multicast eben Probleme hat.

Ich bin in multicast nicht wirklich kundig. Das läuft doch nicht über den IP Stack, sondern über Routing Protokolle oder? Anhand der IP aus dem für Multicast reserviertem Bereich erkennt der Router das er das Paket nicht normal schicken kann, ermittelt über Routing Protokolle mögliche Routing Wege/Ziele und leitet das IP Paket evtl. dupliziert an jedes Ziel weiter. Läuft ja beim point2point Routing bis auf die Duplizierung auch nicht anders.

Wenn dem so wäre, dann läge das Problem nicht an der Übertragungsqualität im WLAN an sich, sondern an der Qualität des Routersoftware, oder bin ich hier auch wieder auf dem falschen Dampfer?

[MarkusS]

Falscher Dampfer - nicht mal der richtige Ozean.

Das "Routing" in KNXnet/IP Routing hat nichts mit IP-Routing-Protokollen (RIP, OSPF, ...) zu tun sondern bezieht sich auf die Linien- bzw. Bereichskopplerfunktion.

Für Multicast braucht der KNX-IP-Router eigentlich nicht mal wissen was das Default Gateway seines IP-Netzes ist, geschweige denn dass er IP-Routen kennen muss. Solange Kupfer im Spiel ist kotzt der KNX-IP-Router die Pakete einfach ins LAN, Ziel 223.irgendwas. Switches schicken die einfach erstmal auf allen Ports raus (außer auf dem wo das Paket reinkam), Router routen die in alle direkt angeschlossenen Netze. Es gibt da noch ein paar nette Verfahren auf Netzwerkebene dass Teilnehmer subskribieren können und dass Switches und Router lernen hinter welchen Ports / in welchen Netzen tatsächlich Abonnenten sind und die Pakete nur noch dahin schicken.

Und dann war da noch die Sache mit den WLANs und dem Multicast ...

[tbi]

Ok , noch was aus der Tüte.

Also ein Ethernet Switch, der nicht explicit IGMP kann, kann trotzdem dazwischen sein.

ABER nur einmal.

Warum? Weil er das Packet dann als UDP Broadcast versteht und es an alle Ports weiterleitet. Also über einen solchen Switch geht es gerade noch.

Wenn ein Switch IGMP kann. Dann merkt es sich alle Ports die ein "Join" auf die IGMP Gruppe (das ist der IGMP Port) gemacht haben. Also wenn Du ein IGMP Packet an einen Switch schickst, mit der IGMP Port Adresse 4711, dann erhältst Du in Zukunft alle IGMP Packete für die Gruppe 4711 auf dem Port des Ethernet Switches.

Bei einem IP-TV Kanal wäre der IGMP Port ein Kanal, der geschaut wird. Alle die den Kanal schauen, subscribieren sich auf den IGMP Kanal und erhalten zukünftig alle Packete dazu. Erst mit einem "Leave" oder timeout wird dies wieder verlassen.

Das ist also wie eine intelligente Gießkanne oder ein Forum

Wenn Du also einen Dummen Switch und eine WLAN Router in der Strecke drin hast, dann hast Du auch schon deshalb eine Problem.

Denn der zweite Switch wird das nur noch als UDP Broadcast weitersenden und das wird dann nicht mehr als IGMP verstanden, weil die Info dazu weg ist.

Gute Nacht

Tbi

[tanzbaer]

Falscher Dampfer - nicht mal der richtige Ozean.

Ne, Missverständnis. Mir ging es schon um den Netzwerk Router, nicht um den KNX-IP Router. Alles gut.

[tanzbaer]

Wenn Du also einen Dummen Switch und eine WLAN Router in der Strecke drin hast, dann hast Du auch schon deshalb eine Problem.

Denn der zweite Switch wird das nur noch als UDP Broadcast weitersenden und das wird dann nicht mehr als IGMP verstanden, weil die Info dazu weg ist.

Ok, verstanden. Heisst für mich, dass ich in einem Moment der Langeweile mal die Situationen bei mir wieder herstellen müsste. Aktuell läuft es mit ETRS-4 unter parallels auf dem Mac, die Kiste hängt über LAN an einem TP-Link SG-1024, an dem das wiregate mit tp-uart.

Im ersten Setup (nicht funktionierend): ETRS-4 unter parallels, wlan zu einem alten linkedin router, dort Kabel direkt zum weinzierl linemaster 760. Das war gruselig von der Performance.

Zweites, funktionierendes Setup: ETRS-4 unter parallels, LAN an einem TP-Link SG-1024, Kabel zum weinzierl linemaster-760.

Welchen Verbindungsmodus ich in der ETRS ausgewählt hatte, kann ich allerdings nicht mehr nachvollziehen.

Ist es richtig, dass ein nicht funktionierender Bus- und Gruppenmonitor ein Indiz dafür wäre, dass ich über IP-Routing und nicht IP-Tunneling kommuniziert habe?


Was ich jetzt aber immer noch nicht final verstanden habe, warum bei meinem einfachen Setup: Rechner-WLAN-Router-Kabel-KNX-IP-Router, WLAN ein Grund dafür ist, das es nicht funktioniert.