UDP Steuerungsprotokoll / Control protocol
Re: UDP Steuerungsprotokoll
Im ersten Beitrag steht das Beispiel übrigens noch falsch da
Adv Power SN:171012, OS X 10.8, Windows XP SP3, DSL-Routernetzwerk
USB-PwrCtrl im Bj. 2000 Stil
USB-PwrCtrl im Bj. 2000 Stil
Re: UDP Steuerungsprotokoll
Aber bitte nicht als breaking change.andy hat geschrieben:Bei dem nächsten Updata werde ich möglich machen eine Zahl zu senden. Bitte vergisst ASCII !!! bitte bitte...
-
- Administrator
- Beiträge: 487
- Registriert: Dienstag 15. Januar 2008, 11:51
- Wohnort: Düsseldorf
- Kontaktdaten:
Re: UDP Steuerungsprotokoll
Wir denken immer an ALLE.
LG Andy
LG Andy
-
- Beiträge: 4
- Registriert: Dienstag 14. Juli 2015, 00:53
Re: UDP Steuerungsprotokoll
Hallo ANEL Elektronik!
Wir haben uns ein Gerät (HUT) zur Evaluierung beschafft. Folgende Fragen kamen auf:
- Sendet das Gerät (hier: HUT) auch Quittungen zurück bzw. Events oder muss man den Status pollen? Meint: Erhält man eine Bestätigung (auf Port 77) wenn eine Aktion erfolgreich oder mit Fehler abgeschlossen wurde? Wenn ja, wie ist diese Bestätigungsnachricht aufgebaut?
- Erhält man zudem auch eine Nachricht (Event), wenn an einem Digitaleingang der Signalzustand wechselt? Wenn ja, wie ist diese Eventnachricht aufgebaut?
- Wenn es Events gibt: Welche (sinnvolle) Schaltfrequenz ist an den Digitaleingängen maximal zu erreichen?
- Wenn es Events gibt: Werden mehrere "gleichzeitige" Events in einem UDP Paket signalisiert oder wird für jedes Event ein eigenes UDP Paket gesendet?
- Ist geplant, künftig auch TCP zur Transportsicherung anzubieten? Wenn Nein, welche Alternativen schlagen Sie zur Transportsicherung vor, sprich, welches auf UDP basierende Protokoll würden Sie empfehlen, um den Signaltransport zu sichern? Zum Hintergrund der Frage: UDP Pakete können verloren gehen oder außer Sequenz geraten, insbesondere bei Übertragung über Weitverkehrsnetze.
Vielen Dank, beste Grüße
Walter Weyers
Wir haben uns ein Gerät (HUT) zur Evaluierung beschafft. Folgende Fragen kamen auf:
- Sendet das Gerät (hier: HUT) auch Quittungen zurück bzw. Events oder muss man den Status pollen? Meint: Erhält man eine Bestätigung (auf Port 77) wenn eine Aktion erfolgreich oder mit Fehler abgeschlossen wurde? Wenn ja, wie ist diese Bestätigungsnachricht aufgebaut?
- Erhält man zudem auch eine Nachricht (Event), wenn an einem Digitaleingang der Signalzustand wechselt? Wenn ja, wie ist diese Eventnachricht aufgebaut?
- Wenn es Events gibt: Welche (sinnvolle) Schaltfrequenz ist an den Digitaleingängen maximal zu erreichen?
- Wenn es Events gibt: Werden mehrere "gleichzeitige" Events in einem UDP Paket signalisiert oder wird für jedes Event ein eigenes UDP Paket gesendet?
- Ist geplant, künftig auch TCP zur Transportsicherung anzubieten? Wenn Nein, welche Alternativen schlagen Sie zur Transportsicherung vor, sprich, welches auf UDP basierende Protokoll würden Sie empfehlen, um den Signaltransport zu sichern? Zum Hintergrund der Frage: UDP Pakete können verloren gehen oder außer Sequenz geraten, insbesondere bei Übertragung über Weitverkehrsnetze.
Vielen Dank, beste Grüße
Walter Weyers
-
- Administrator
- Beiträge: 487
- Registriert: Dienstag 15. Januar 2008, 11:51
- Wohnort: Düsseldorf
- Kontaktdaten:
Re: UDP Steuerungsprotokoll
Hallo,
Jede Zustandsänderung sendet eine Quittung (guter Name); Relais und IO.
Wie haben es nicht getestet aber 5 Hz müssten gehen.
"Gleichzeitige" Events senden einen UDP Paket.
Durch die "Quittung" ist TCP nicht notwendig und würde die Antwort verlangsamen. Broadcast wäre nicht mehr möglich. Da gibt es noch Multicast..., da wird's immer komplizierter.
LG Andy
Jede Zustandsänderung sendet eine Quittung (guter Name); Relais und IO.
Wie haben es nicht getestet aber 5 Hz müssten gehen.
"Gleichzeitige" Events senden einen UDP Paket.
Durch die "Quittung" ist TCP nicht notwendig und würde die Antwort verlangsamen. Broadcast wäre nicht mehr möglich. Da gibt es noch Multicast..., da wird's immer komplizierter.
LG Andy
-
- Beiträge: 4
- Registriert: Dienstag 14. Juli 2015, 00:53
Re: UDP Steuerungsprotokoll
Hallo Andy,
vielen Dank für die umgehende Antwort! Darf ich an 2 Stellen noch mal nachhaken?:
- Zu den Quittungen: In welchem Datenformat kommen diese? Hierzu finde ich keine Beschreibung.
- Transportsicherung: UDP Pakete gehen definitiv im Internet verloren. Bis zu 10% sind auf engen Leitungen und mit QoS-Priorisierung keine Seltenheit. Damit gibt es auch ein nicht zu vernachlässigendes Risiko, dass Quittungen nicht eintreffen. Wie sollte Ihrer Empfehlung nach mit dieser Situation umgegangen werden? Man könnte z.B. ein Timeout setzen und auf das Quittungs UDP-Paket warten. Wenn es nicht kommt, dann was? A) die Aktion erneut auslösen oder b) den Gesamtstatus abfragen? Oder c) noch ein anderes Verfahren? Welche Empfehlung geben Sie hier?
Die UDP-Quittung ersetzt also leider keine implizite Transportsicherung, wie TCP. Und TCP, sobald die Verbindung steht, ist nicht erkennbar langsamer, als UDP, es sei denn, das Übertragungsmedium ist schlecht und Pakete müssen wiederholt gesendet werden. Aber genau diesen Overhead nimmt man ja dankend für die Transportsicherung in Kauf. Broadcast und Multicast enden in der Regel spätestens am nächsten Router oder Gateway und kann zudem zur Transportsicherung, genau wie UDP, nur bedingt und auf Logikebene herhalten.
Viele Grüße
Walter
vielen Dank für die umgehende Antwort! Darf ich an 2 Stellen noch mal nachhaken?:
- Zu den Quittungen: In welchem Datenformat kommen diese? Hierzu finde ich keine Beschreibung.
- Transportsicherung: UDP Pakete gehen definitiv im Internet verloren. Bis zu 10% sind auf engen Leitungen und mit QoS-Priorisierung keine Seltenheit. Damit gibt es auch ein nicht zu vernachlässigendes Risiko, dass Quittungen nicht eintreffen. Wie sollte Ihrer Empfehlung nach mit dieser Situation umgegangen werden? Man könnte z.B. ein Timeout setzen und auf das Quittungs UDP-Paket warten. Wenn es nicht kommt, dann was? A) die Aktion erneut auslösen oder b) den Gesamtstatus abfragen? Oder c) noch ein anderes Verfahren? Welche Empfehlung geben Sie hier?
Die UDP-Quittung ersetzt also leider keine implizite Transportsicherung, wie TCP. Und TCP, sobald die Verbindung steht, ist nicht erkennbar langsamer, als UDP, es sei denn, das Übertragungsmedium ist schlecht und Pakete müssen wiederholt gesendet werden. Aber genau diesen Overhead nimmt man ja dankend für die Transportsicherung in Kauf. Broadcast und Multicast enden in der Regel spätestens am nächsten Router oder Gateway und kann zudem zur Transportsicherung, genau wie UDP, nur bedingt und auf Logikebene herhalten.
Viele Grüße
Walter
-
- Administrator
- Beiträge: 487
- Registriert: Dienstag 15. Januar 2008, 11:51
- Wohnort: Düsseldorf
- Kontaktdaten:
Re: UDP Steuerungsprotokoll
Hallo Walter,
Packet ist in dem Protokoll beschrieben:
Beispiel:
NET-PwrCtrl:NET-CONTROL :192.168.178.148:255.255.255.0:192.168.178.1:0.4.163.10.9.107:Nr. 1,1:Nr. 2,1:Nr. 3,1:Nr. 4,0:Nr. 5,0:Nr. 6,0:Nr. 7,1:Nr. 8,1:0:80:IO-1,0,0:IO-2,0,0:IO-3,0,0:IO-4,0,0:IO-5,0,0:IO-6,0,0:IO-7,0,0:IO-8,0,0:27.7°C:NET-PWRCTRL_04.0
hängt auch von dem Typ der Leiste.
Wir empfehlen UDP NUR für internes Netz. Für Internet haben wir Ajax.
Sollte das Packet verloren gehen kann man nachfragen: 'wer da=?'
Wir haben mit UDP sehr gute Erfahrungen gemacht. Kunden haben nicht gegenteiliges gemeldet.
LG Andy
Packet ist in dem Protokoll beschrieben:
Beispiel:
NET-PwrCtrl:NET-CONTROL :192.168.178.148:255.255.255.0:192.168.178.1:0.4.163.10.9.107:Nr. 1,1:Nr. 2,1:Nr. 3,1:Nr. 4,0:Nr. 5,0:Nr. 6,0:Nr. 7,1:Nr. 8,1:0:80:IO-1,0,0:IO-2,0,0:IO-3,0,0:IO-4,0,0:IO-5,0,0:IO-6,0,0:IO-7,0,0:IO-8,0,0:27.7°C:NET-PWRCTRL_04.0
hängt auch von dem Typ der Leiste.
Wir empfehlen UDP NUR für internes Netz. Für Internet haben wir Ajax.
Sollte das Packet verloren gehen kann man nachfragen: 'wer da=?'
Wir haben mit UDP sehr gute Erfahrungen gemacht. Kunden haben nicht gegenteiliges gemeldet.
LG Andy
-
- Beiträge: 4
- Registriert: Dienstag 14. Juli 2015, 00:53
Re: UDP Steuerungsprotokoll
Hallo Andy,
erneut vielen Dank für die Erläuterungen!
Die Quittungs-Nachricht entspricht also der Standard-Nachricht und liefert somit stets den Gesamtstatus. Verstanden.
Was Ajax angeht, meine ich irgendwo im Forum gelesen zu haben, dass über dieses Protokoll (XML HTTP-Request) leider keine Quittung (synchron oder asynchron) zurückgemeldet wird. Ist das noch immer so oder bin ich da falsch informiert?
Gruß, Walter
erneut vielen Dank für die Erläuterungen!
Die Quittungs-Nachricht entspricht also der Standard-Nachricht und liefert somit stets den Gesamtstatus. Verstanden.
Was Ajax angeht, meine ich irgendwo im Forum gelesen zu haben, dass über dieses Protokoll (XML HTTP-Request) leider keine Quittung (synchron oder asynchron) zurückgemeldet wird. Ist das noch immer so oder bin ich da falsch informiert?
Gruß, Walter
-
- Beiträge: 4
- Registriert: Dienstag 14. Juli 2015, 00:53
Re: UDP Steuerungsprotokoll
Hallo Andy,
könnten Sie bitte zu der Frage nach Quittungen und Events über das HTTPRequest Protokoll (Ajax) noch kurz etwas sagen?
Vielen Dank unf freundliche Grüße
Walter
könnten Sie bitte zu der Frage nach Quittungen und Events über das HTTPRequest Protokoll (Ajax) noch kurz etwas sagen?
Vielen Dank unf freundliche Grüße
Walter
-
- Administrator
- Beiträge: 487
- Registriert: Dienstag 15. Januar 2008, 11:51
- Wohnort: Düsseldorf
- Kontaktdaten:
Re: UDP Steuerungsprotokoll
Hallo,
Bei HTTP Request muss man den Status pollen. Es geht über TCP also kein Event.
Im http://anel-elektronik.de/ba.zip gibt es ein Beispiel: "ADV/Ajax Schnittstelle"
LG Andy
Bei HTTP Request muss man den Status pollen. Es geht über TCP also kein Event.
Im http://anel-elektronik.de/ba.zip gibt es ein Beispiel: "ADV/Ajax Schnittstelle"
LG Andy