Ich betreibe einige uC, welche auf einem RTOS laufen und dort auf einen integrierten Ethernet Stack zugreifen können. Nun möchte ich eine Fremdapplikation integrieren, welche mit einer App arbeitet. Durch auslösen eines Knopfes auf der App, wird eine Nachricht an deren Server gesendet, welche diese Nachricht an meinen Server weiterleitet. Hierzu habe ich ein eigenes Backend geschrieben und deren Protokoll integriert, dieser Teil läuft auch ohne Probleme. Was mir noch Probleme bereitet, ist die Verbindung zwischen meinem eigenen Server und meinen uCs. Zuerst habe ich eine REST Schnittstelle implementiert und polle von den uCs zum Server. Da die Reaktionszeit kurz sein soll, polle ich inzwischen mit noch 200ms Abstand. Dies führt aber dazu, dass sehr viel Traffic entsteht und die meiste Zeit nichts zu melden ist. Meine uC sind entweder über LAN angebunden, oder über einen SIM Karten Router. Besonders bei den SIM Karten ist der hohe Traffic ärgerlich, da ich hohe Kosten trage. Welche Möglichkeit gibt es, um die Kommunikation umzudrehen? Meine uC besitzen über keine feste IP, noch sind sie von aussen zugänglich, da meist hinter einem Router. Ich suche eine datensparende Lösung, um Benachrichtigungen meines Servers schnell mitzubekommen und die auf einem RTOS oder Barebone laufen.
Angehängte Dateien:
-
Notify.png
21 KB
Netzwerkverbindung vom Client zum Server aufbauen und dauherhaft bestehen lassen. Server kann dann über diese Netzwerkverbindung Daten an den Client senden, jederzeit, wann auch immer er Lust hat. Das setzt natürlich voraus, daß man auf beiden Seiten die Software in der Hand hat. Ein ganz simples Beispiel für ein derartiges dauerhaftes Protokoll wäre telnet.
Patrick B. schrieb: > Ich würde mal MQTT in den Raum werfen. Viel zu einfach - das Zeugs stammt aus dem vorigen Jahrhundert.
:
Bearbeitet durch User
Operator S. schrieb: > Da die Reaktionszeit kurz sein soll, polle ich inzwischen mit noch 200ms > Abstand. Dies führt aber dazu, dass sehr viel Traffic entsteht und die > meiste Zeit nichts zu melden ist. Verzögere Server-seitig die Antwort so lange, bis etwas "zu melden" ist oder der Client die Verbindung von sich aus wieder trennt. > Ich suche eine datensparende Lösung Sparsam wären UDP Pakete von der Quelle zum Ziel, dafür muss das Ziel einen entsprechenden Listener laufen lassen.
:
Bearbeitet durch User
Da muss doch keiner was verzögern. Eine stinknormale simple TCP Verbindung bleibt offen bis zum Sankt Nimmerleinstag und ist bidirektional, beide Gegner können nach belieben senden.
Operator S. schrieb: > entweder über LAN angebunden, oder über einen SIM Karten > Router J. S. schrieb: > bis zum Sankt Nimmerleinstag LAN ja, SIM Karten Router weiss nicht
J. S. schrieb: > Eine stinknormale simple TCP > Verbindung bleibt offen bis zum Sankt Nimmerleinstag CGNAT-Gateways (die ihm in den meisten Mobilfunknetzen begegnen werden) haben oft geizige Timeouts, man sollte schon alle paar Minuten Keepalives schicken. Steve van de Grens schrieb: > Sparsam wären UDP Pakete von der Quelle zum Ziel, dafür muss das Ziel > einen entsprechenden Listener laufen lassen. ...und noch öfter Keepalives schicken als bei TCP.
J. S. schrieb: > Eine stinknormale simple TCP > Verbindung bleibt offen bis zum Sankt Nimmerleinstag .. oder auch nicht, Router trennen meist nach Timeout die kommende Richtung. Operator S. schrieb: > oder über einen SIM Karten Router. > > Meine uC besitzen über keine feste IP, > noch sind sie von aussen zugänglich, > da meist hinter einem Router.
Kommt drauf an, ob es eine Hobbybastelei ist, oder jahrelang unauffällig störungsfrei laufen soll. Soll es auch die unzähligen Probleme behandeln, die alle paar Jahre mal auftreten? Und sollen alte Geräte mit neuen, erweiterten Servern zusammen arbeiten? Irgend etwas, bei dem man ab und zu den Reset-Knopf drücken muss, bekommt man selbst zustande. Wenn es unauffällig und zuverlässig werden soll, kommst du wohl mit einem ausgereiften Konzept wie MQTT besser weg.
Am wenigsten Änderungen wird long-polling brauchen. Der Server antwortet erst wenn was zum antworten da ist. Neumodischer geht es mit websockets. Wenn es außerhalb http sein darf auch mqtt
Harald K. schrieb: > Netzwerkverbindung vom Client zum Server aufbauen und dauherhaft > bestehen lassen. Welche Art von Verbindungen gibts denn? Vor allem welche, die auch auf einem uC ohne grosse Ressourcen möglich sind. Patrick B. schrieb: > Ich würde mal MQTT in den Raum werfen. Da hab ich schon gehört, dass die Zeit zwischen Server und Endgerät schon relativ lange sein kann. Lange ist in meinem Fall alles was über eine Sekunde lang dauert. Hast du eine Zeitangabe, womit man etwa rechnen muss? Steve van de Grens schrieb: > Verzögere Server-seitig die Antwort so lange, bis etwas "zu melden" ist > oder der Client die Verbindung von sich aus wieder trennt. Das habe ich mir auch schon gedacht, kenne mich aber mit den Netzwerkprotokollen nicht genug aus. Wenn ich nun ein GET Request an das Backend mache, kann dann das Backend diesen Request auch erst z.B. morgen beantworten? Und so lange bleibt die Verbindung bestehen? Merke ich vom uC aus, wenn die Verbindung abbricht und ich nichts mehr vom Server erwarten kann?
Hmmm schrieb: > J. S. schrieb: >> Eine stinknormale simple TCP >> Verbindung bleibt offen bis zum Sankt Nimmerleinstag > > CGNAT-Gateways (die ihm in den meisten Mobilfunknetzen begegnen werden) > haben oft geizige Timeouts, man sollte schon alle paar Minuten > Keepalives schicken. Alle paar Minuten ein Keepalive senden sollte kein Problem sein, von mir aus auch 1 mal pro Minute. Nur steh ich irgendwie auf dem Schlauch, wie ich eine TCP Verbindung aufmache. Bin ich da mit https schon zu weit weg? Oder ist das eine Art der https Verbindung? Xanthippos schrieb: > Kommt drauf an, ob es eine Hobbybastelei ist, oder jahrelang unauffällig > störungsfrei laufen soll. > > Soll es auch die unzähligen Probleme behandeln, die alle paar Jahre mal > auftreten? Und sollen alte Geräte mit neuen, erweiterten Servern > zusammen arbeiten? Es soll jahrelang arbeiten können, wobei die Firmware immer updatebar bleibt. Es ist jeweils nur ein Server der verschiedene Devices abhandeln soll (>1000 mit der Zeit). Es ist keine Hobbybastelei.
> Wenn ich nun ein GET Request ... erst z.B. morgen beantworten? Reiner Zufall. Das Protokoll ist halt für Browser konzipiert, an denen ein Mensch sitzt. Kann jede Library machen, wie sie will. > Merke ich vom uC aus, wenn die Verbindung abbricht Manchmal. Kann auch sein, du bekommst nur Fehlermeldungen, wenn das Senden nicht klappt. Nicht aber wenn dein Request ankommt, aber die andere Seite später nicht mehr antworten kann. > Nur steh ich irgendwie auf dem Schlauch Solltest vielleicht erst mal ein Leerbuch für das Schichtenmodell durcharbeiten. Welche Aufgaben IP, TCP, HTTP und HTTPS haben. > Es soll jahrelang arbeiten können Dann solltest du erst mal ein Tutorial durcharbeiten, das erklärt, warum Protokolle wie MQTT so aufwendig sind und warum es erfahrene Entwicklter mehrere Versionen brauchen, bis alles rund läuft.
Xanthippos schrieb: > Solltest vielleicht erst mal ein Leerbuch für das Schichtenmodell > durcharbeiten. Welche Aufgaben IP, TCP, HTTP und HTTPS haben. Hast du eine Empfehlung? Das fehlende Wissen in diesem Bereich ist tatsächlich etwas, was immer wieder zurückfällt. Solange es im Firmwarebereich bleibt oder im Backend habe ich das gelernt, aber die Verbindung dazwischen komischerweise nie.
Operator S. schrieb: > Da hab ich schon gehört, dass die Zeit zwischen Server und Endgerät > schon relativ lange sein kann. Lange ist in meinem Fall alles was über > eine Sekunde lang dauert. Hast du eine Zeitangabe, womit man etwa > rechnen muss? Eine Sekunde ist sehr lang. Kommt natürlich auf den Payload und das Netzwerk an. https://youtu.be/5Wg8wkLySqs?si=jHyX3scJSwQcQUm4 Hier werden 10 000 Clients aktiv und die Reaktionszeit liegt je nach Broker unter 250 ms.
Operator S. schrieb: > Das habe ich mir auch schon gedacht, kenne mich aber mit den > Netzwerkprotokollen nicht genug aus. Wenn ich nun ein GET Request an das > Backend mache, kann dann das Backend diesen Request auch erst z.B. > morgen beantworten? Jein. Eine Minute geht auf jeden Fall. Mehr Verzögerung hängt von den Netzwerk-Komponenten ab. Bei uns auf der Arbeit trennt die Firewall alles, was 30 Minuten lang inaktiv ist. Aber ein Verbindungsaufbau alle 30 Minuten ist doch gut. besser als einer alle 200 ms. Der Client kann Verbindungsverlust einfach eine neue aufbauen. Oder der Server antwortet nach ein Paar Minuten "nix los", um die Trennung durch Firewall (oder andere Komponenten) zu verhindern. Allerdings muss der Client trotzdem fähig sein, bei Bedarf eine neue Verbindung aufzubauen. Ich würde mich nie darauf verlassen, dass eine einmal geöffnete Verbindung für immer verbunden bleibt.
Operator S. schrieb: > Wenn ich nun ein GET Request an das > Backend mache, kann dann das Backend diesen Request auch erst z.B. > morgen beantworten? Und so lange bleibt die Verbindung bestehen? Grundsätzlich ja, aber wenn solange gar nichts über die Leitung kommt, wird vermutlich irgendwo ein Timeout zuschlagen; das willst Du prinzipiell ja auch um zu erkennen, ob die Gegenstelle (und alle Geräte die dazwischen liegen) überhaupt noch lebt. Aber Du kannst ja erstmal einen Teil der Antwort senden, z.B. die Header und anschließend in regelmäßigen Abständen halt ein einzelnes Leerzeichen, Zeilenvorschub o.ä. (die haben im Body einer http-Antwort normal eh keine Signifikanz) als keep-alive und wenns tatsächlich was zu melden gibt, den kompletten restlichen Body; sollte die Verbindung irgendwann mal mit einem Fehler abbrechen, dann startest Du einfach einen neuen Get-Request, ebenso wenn Du eine komplette Antwort erhalten hast. Falls Du Deine http-Empfangsroutine am µC nicht so modifizieren kannst, daß empfangene keep-alive Zeichen gar nicht erst im Empfangspuffer landen, dann mußt Du die Verbindung außerdem rechtzeitig mit einer Leermeldung abschließen, bevor dem µC der Speicher knapp wird. Wie oft Du die keep-alives senden mußt, insbesondere über Mobilfunk-Verbindungen, kannst Du ja testen, einfach mit ein paar Sekunden beginnen und dann steigern bis es irgendwann nicht mehr klappt, dann nimmst Du den letzten Wert mit dems noch funktioniert hat. Mach die Intervalle aber nicht zu groß, damit Deine Clients auch zeitnah mitbekommen, wenn der Server doch mal einen unkontrollierten Neustart macht.
Operator S. schrieb: > Merke ich vom uC aus, wenn die Verbindung abbricht und ich nichts mehr > vom Server erwarten kann? Normalerweise ja. Die Trennung wird in beide Richtungen durch ein RST Paket signalisiert. Allerdings kann es bei technischen Störungen auch passieren, dass eine offene Verbindung unbemerkt verloren geht ohne dass das abschließende RST Paket übertragen werden kann. Derjenige, der danach etwa sendet, erkennt dies in Form eines Timeouts (typisch nach 60 Sekunden), weil er keine Bestätigung empfängt. Das führt zur Trennung des TCP Sockets durch den IP Stack. Die andere Seite, die passiv auf Daten wartet, merkt den Verbindungsverlust nicht. Deswegen ist es klug, dort auf Applikations-Ebene einen Receive-Timeout zu implementieren. Informiere dich mal über UDP, das könnte in deinem Fall einfacher sein, weil es ohne Verbindungen arbeitet. UDP kann man mit Postkarten vergleichen. Man schickt sie einfach ab, und meistens kommen sie zeitnah an.
:
Bearbeitet durch User
Patrick B. schrieb: > Ich würde mal MQTT in den Raum werfen. Warum eigentlich immer MQTT? Oder anders gefragt: was spricht gegen ZeroMQ?
Ein T. schrieb: > Patrick B. schrieb: >> Ich würde mal MQTT in den Raum werfen. > > Warum eigentlich immer MQTT? Oder anders gefragt: was spricht gegen > ZeroMQ? Das sieht ja eigentlich ganz einfach aus https://zeromq.org/languages/python/ und braucht keinen Broker Noch'ne Frage: warum nimmt Du eigentlich eine App, die eine Hersteller-Cloud braucht, welche Vorteile hat das für Dich? Wenn der hersteller nicht mehr mag, ist es aus.
:
Bearbeitet durch User
Operator S. schrieb: > Merke ich vom uC aus, wenn die Verbindung abbricht und ich nichts mehr > vom Server erwarten kann? Häufig, aber nicht zwingend. In deiner speziellen Situation hast du zwischen µC und Server ja noch einen Mobilfunkprovider mit Carrier-Grade-NAT. Wenn da beim CGNAT-Gateway deine Verbindung aus der Tabelle rausfällt (d.h. die Übersetzung der IP-Adresse), dann können beide Endpunkte nicht mehr miteinander reden. Und dafür gibt es weder eine vorgesehene Signalisierung des Gateways zu den Endpunkten noch würde danach ein RST-Package duchkommen können falls der Server da was merken würde. Da hilft also nur einen Request vom µC zum Server zu senden und bei ausbleibender Auntwort die Verbindung neu aufzubauen. Bei CGNAT würde ich so etwas mindestens einmal pro Minute machen, aber … Du musst dir also im Sinne von Real-Time-Anwendungen die Frage stellen, welche Reaktionszeit auf Nachrichten Server->µC maximal erlaubt ist. Und dann musst du z.B. MQTT-Pings innerhalb der existierenden Verbindung mit einem Intervall senden, so dass Intervall+Timeout+Neuaufbau unter dieser maximalen Reaktionszeit bleibt. Natürlich nur falls du wirklich harte Anforderungen hast. Wenn ein "in 99.9% der Fälle geht es gut" ausreicht, dann tut es auch ein seltenerer Ping. Aber im Worst-Case merkst du eben erst durch die ausbleibende Antwort (oder eine Fehlermeldung wenn der Request schon nicht gesendet werden kann) dass du gerade keine Nachrichten vom Server erhältst. Du musst auch berücksichtigen, dass der Server die Nachrichten puffern muss (bei MQTT also mit persistent arbeiten), damit der µC dann nach dem Reconnect die ihm fehlenden Informationen erhält. Wenn es über einen Status hinausgeht (also z.B. auf 5 Messages müssen auch 5 Aktionen des µC erfolgen), dann muss dein µC dem Server auch die Verarbeitung jeder einzelnen Message bestätigen, denn sonst könnten da welche während so einer Unterbrechung der Verbindung unter den Tisch fallen (analog zu Interrupts beim µC, wenn da ein Timer z.B. dreimal überläuft bis der zugehörige Interrupt verarbeitet wird). Für eine wirklich zuverlässige Kommunikation fällt da leider auch einiges an Traffic an. Da musst du dann bewerten, wieviel dir diese Sicherheit bzw. bestimmte Reaktionszeiten wert sind.
Steve van de Grens schrieb: > Informiere dich mal über UDP, das könnte in deinem Fall einfacher sein, > weil es ohne Verbindungen arbeitet. UDP kann man mit Postkarten > vergleichen. Man schickt sie einfach ab, und meistens kommen sie zeitnah > an. Vergiss UDP wenn du du NAT dazwischen hast. Da musst du ja noch öfter als bei TCP keep-alive-Packages senden damit das Gaetway die (bei UDP nicht wirklich vohandene) "Verbindung" noch als existent betrachtet. Im Endeffekt hast du da in dieser Situation mehr Aufwand (und Traffic) als bei TCP.
Ralf D. schrieb: > Bei CGNAT würde ich so etwas mindestens einmal pro Minute machen Nicht übertreiben, in Mobilfunknetzen werden auch Push-Connections (FCM, IMAP IDLE etc.) offen gelassen, ohne dass man die Geräte so oft weckt. Bei Vodafone scheint der Timeout bei 10 Minuten zu liegen. Ralf D. schrieb: > Vergiss UDP wenn du du NAT dazwischen hast. Ja. Da sind die Timeouts zwar heutzutage wegen SIP auch oft länger (10-15 Minuten), aber man kann sich nicht darauf verlassen, dass das für alle Ports und Gegenstellen gilt.
Stephan S. schrieb: > Ein T. schrieb: >> Patrick B. schrieb: >>> Ich würde mal MQTT in den Raum werfen. >> >> Warum eigentlich immer MQTT? Oder anders gefragt: was spricht gegen >> ZeroMQ? > > Das sieht ja eigentlich ganz einfach aus > https://zeromq.org/languages/python/ und braucht keinen Broker Sehr richtig. Und es ist dabei sogar schnell genug, um in Clusterprodukten wie Apache Storm und Apache Heron genutzt zu werden...
Ich kannte ZeroMQ bisher nicht. Der Vergleich hier würde mich eher Richtung MQTT tendieren lassen. https://stackshare.io/stackups/mqtt-vs-zeromq Bzw. https://www.hivemq.com/article/mqtt-vs-zeromq-for-iot/ Je nach Bedarf sind bei MQTT QOS möglich. ZeroMQ ist mehr lowlevel als MQTT. Das Problem vom TO wird meines Erachtens mit beiden Technologien lösbar sein. Als Beispiel hier ein Parkplatzmonitor-Projekt https://github.com/koutselakismanos/IoTParkingLot Wobei mich noch interessieren würde ob es wirklich wichtig ist innerhalb einer Sekunde das Signal erfassen zu müssen oder ob es auch ausreicht einen genauen Timestamp zu schicken. Grüße Patrick
:
Bearbeitet durch User
Patrick B. schrieb: > Ich kannte ZeroMQ bisher nicht. Der Vergleich hier würde mich eher > Richtung MQTT tendieren lassen. Das bleibt Dir unbenommen. Aus meiner Sicht ist es allerdings so, daß MQTT eine zentrale Infrastrukturkomponente benötigt, nämlich den Broker. Solche Infrastrukturkomponenten und die Hardware, auf der sie laufen, haben leider die unangenehme Eigenschaft, bisweilen auszufallen, und wenn man bei MQTT keine Vorkehrungen dafür trifft, gehen dann Nachrichten verloren. Und wenn präventiv Vorkehrungen gegen Ausfälle getroffen werden, dann reden wir von einem hochverfügbaren Setup aus mindestens drei MQTT-Brokern, einer Floating IP und etwas zu deren Verwaltung, also so etwas wie Corosync/Pacemaker oder Keepalived und so etwas sie STONITH, und zusätzlich natürlich das kleine Einmaleins des Betriebes wichtiger Infrastrukturen: Monitoring, Alarming, und der ganze Rest, der zwingend dazu gehört. Dann ist so ein Setup leider nicht mehr so einfach, wie es auf den ersten Blick aussieht. Demgegenüber hat ZMQ IMHO einige Vorzüge, scheint mir, aber wie immer: YMMV, und Deine Wahl kann natürlich anders aussehen als meine. Man darf dabei natürlich auch nicht vergessen, daß es bereits eine Vielzahl an Open- und ClosedSource-Produkten gibt, die bereits MQTT sprechen. Wer solche Produkte einsetzen will oder muß, wäre natürlich verrückt, wenn er nicht auf MQTT setzen würde. Aber wer selbst etwas implementiert, ist mit ZeroMQ gut bedient, und im Zweifelsfall lassen sich die beiden Technologien natürlich auch relativ gut und einfach miteinander kombinieren -- zum Preis weiterer Infrastrukturkomponenten allerdings, für die womöglich zumindest teilweise änhliches gilt wie das oben bereits erwähnte.
Wie kann denn eine Architektur wie oben vom TO beschrieben in ZeroMQ in Ausfallsicher aussehen? Den Broker musst du doch bei ZeroMQ durch eine eigene Entwicklung ersetzen, oder? Damit ist diese auch wieder zentral und muss eine entsprechende Verfügbarkeit haben. Grüße Patrick
Patrick B. schrieb: > Wie kann denn eine Architektur wie oben vom TO beschrieben in ZeroMQ in > Ausfallsicher aussehen? > > Den Broker musst du doch bei ZeroMQ durch eine eigene Entwicklung > ersetzen, oder? Damit ist diese auch wieder zentral und muss eine > entsprechende Verfügbarkeit haben. ZeroMQ puffert senderseitig, wenn sein Gegenüber ausgefallen ist. :-)
Das wäre jetzt eine Funktion die müsste man bei MQTT manuell nachprogrammieren. Das stimmt. Über dieses Thema muss man sich ohnehin einiges an Gedanken machen: - Welcher Zeitraum muss gespeichert werden können (Speicherplatz)? - Was passiert wenn Datensätze fehlen? - Was passiert wenn 1000 Geräte gleichzeitig Daten schicken möchten ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.