Hi Leute, ich möchte mit dem Raspberry Pi Ein- und Ausgänge über das Internet einlesen und steuern. Dazu habe ich einen Apache Server mit PHP auf den Raspberry installiert und möchte darüber verschiedene Befehle bidirektional übertragen. Leider habe ich keine Ahnung welche Möglichkeiten es dazu gibt. Ich mir das so vor, ein PC, Android Phone etc. öffnet eine PHP Session auf dem Raspberry. Anfragen könnten ganz einfach abgehandelt werden. Jedoch weiss ich nicht, ob es funktioniert eine Verbindung offen zu halten, sodass auch der Raspberry Pi zu einem beliebigen Zeitpunkt an den PC zurücksenden kann. Welche Möglichkeiten, Funktionsweisen oder Vorgehensweisen gibt es dazu. Natürlich könnte ich eine einfache TCP/IP Verbindung aufbauen, aber da ich den Zugriff auch über eine Webpage ermöglichen möchte, will ich möglichst nur eine Zugriffsart implementieren. Selbst Stichpunkte oder Vorschläge würden mir weiterhelfen. Webtechnisch habe ich leider wenig Ahnung. Irgendwie muss das ja gehen. Ich denke daran an mein Online Banking Portal. Nach einer bestimmten Zeit werde ich automatisch ausgeloggt. Das passiert natürlich erstmals Serverseitig, dennoch bekomme ich eine Nachricht, dass ich abgemeldet wurde. So denke ich es gibt da Möglichkeiten. Vielen Dank!
Hallo Thomas, Du suchst 'HTTP push'. Eventuell geht auch AJAX noch in Deine Richtung. Viel Erfolg, Frank
Die eine Möglichkeit ist, über JavaScript regelmäßig zu pollen ob der Server neue Daten hat. Eine andere Möglichkeit sind WebSockets (ständige Verbindung zwischen Client und Server), z.B. mit websocketd.
:
Bearbeitet durch Admin
Thomas schrieb: > Ich denke > daran an mein Online Banking Portal. Nach einer bestimmten Zeit werde > ich automatisch ausgeloggt. Das passiert natürlich erstmals > Serverseitig, dennoch bekomme ich eine Nachricht, dass ich abgemeldet > wurde. So denke ich es gibt da Möglichkeiten. > > Vielen Dank! das macht java script auf client seite. wenn du die seite offen hast und nichts tust ist irgendwann die session abgelaufen auf dem server. da der client zyklisch nachfragt ob er noch angemeldet ist ist dann deine Nachricht. das gleiche kannst du mit nem cookie auch auf client seite lösen wenn du davon ausgehen kannst dass er nicht manipuliert wird. oder als doppelte sicherheit. so oder so du musst bei php zyklisch nachfragen. ansonsten brauchst du installierte software
Schon Mal vielen Dank für die Tipps und die Erklärung!!! Ajax hab ich gleich mal ausprobiert. Läuft als Webpage richtig gut. Die Methode im allgemeinen wäre perfekt! Finde es nur schwer einen Java-Client (Darf auch ein C++ Client sein) zu schreiben, der eine "Ajax"-Page anfragt und eben auch Javascript ausführen kann. Server auf Java-basis (Servlets), welche Ajax unterstützen gibt es einige. Selbstgebasteltes Polling möchte ich nicht so anwenden (Ajax wäre ok) Bin mir nicht sicher was alles hinter den Javascript Befehlen für Ajax steckt. Im Grunde habe ich Ajax so verstanden, dass einfach ein erneuter Request an den Server gestellt wird, dieser aber asynchron beantwortet werden kann. Die Verbindung wird einfach solange offen gehalten. Dies könnte ich natürlich auch tun. Einfach einen einfachen Http Request an den Server stellen und auf eine Antwort warten, welche eventuell "unendlich" lang auf sich warten lässt. Doch ist es nicht so, dass der Server diese Verbindung eventuell nach einer bestimmten Zeit einfach schließt? Ok in diesem Fall sende ich einfach erneut den Request. Nach welcher Zeit schließt der Server die Verbindung? Dies ist sicherlich abhängig von der Apache Konfiguration. Lösen die Funktionen bei der Verwendung von Ajax unter Javascript dies auch so? Bauen diese immer wieder erneut eine Verbindung auf oder steckt da noch mehr dahinter? Ich habe dies mal ausprobiert.Ich sende einen einfachen Request per Java. Ich frage eine php-Datei an. Diese php-Datei endet in einer Endlosschleife. Bis zum Ende der Verbindung vergehen ca. 35sec. Baue ich in die php-Datei eine Sleep Anweisung von 60sec ein, verlängert sich die Zeit bis zur Schließung der Verbindung um 60sec also auf ca 105sec. Benutze ich einen Webbrowser und rufe dort eine "Ajax" Seite auf welche nach dem Laden einen Teil der Webpage von der gleichen php-Datei bekommen soll funktioniert dies super. Es gibt keinen Abbruch. Egal, ob mit oder ohne Sleep Funktion. Allerdings mit Endlosschleife. Die Seite bleibt sauber bestehen. Die Endlosschleife im php-Skript fragt ab, ob eine Datei am Server existiert. Ist diese Vorhanden, bricht die "Endlosschleife" ab. Nach bis zu ca 35sec konnte ich die Endlosschleife abbrechen lassen und die Webpage wurde upgedatet. Bei einem Test wesentlich länger als 35sec wurde die Webpage nicht mehr upgedatet. Es entsteht ein Fehler mit dem Status 500 (Serverfehler) anschließend muss man auch wieder sehen, dass die Seite erneut angefragt wird. Stehen dann sonst irgendwelche Automatismen hinter den Funktionen von Javascript für Ajax? Für weitere Anregungen bin ich natürlich Dankbar. Der Vorschlag Ajax hat mir schon sehr gut gefallen. Ich werde dies wohl so lösen. Dennoch, gibt es in HTML5 nicht schon etwas "besseres"/"professionelles" ?
Muß es denn unbedingt http sein, wenn der Client eh kein Browser ist?
Auf Client-Seite genügt ein einfacher TCP-Socket. Damit setzt man ein simples "handgestricktes" HTTP-POST-Statement ab, um z.B. eine PHP-Datei auf dem Server abzurufen. So bekommt man Daten vom Server, die Daten des Clienten sendet man als Parameter im POST-Request mit ... Mache gerade sowas für eine Personal-Zeiterfassung, bei der auf Clientseite ein Arduino mit RFID-Leser, einigen Tasten, LCD und Ethernet steht, auf Server-Seite ein "gewöhnlicher" Apache mit PHP (für Entwicklungs- und Testzwecke XAMPP).
Rolf Magnus schrieb: > Muß es denn unbedingt http sein, wenn der Client eh kein Browser > ist? Ist schon ok, denn damit hat man ohne viel Aufwand einen fertigen Multi-Client-fähigen Server - ist schon verlockend. Man kann den HTTP-Datenverkehr ja auch ordentlich abspecken, für eine Maschine-Maschine-Kommunikation müssen nicht unbedingt oppulente Webseiten ausgetauscht werden, es genügt "Basiskommunikation" mit POST und GET.
Thomas schrieb: > Im Grunde habe ich Ajax so verstanden, dass einfach ein erneuter Request > an den Server gestellt wird, dieser aber asynchron beantwortet werden > kann. Die Verbindung wird einfach solange offen gehalten. Die Anfrage wird beantwortet, so schnell es der Server kann, es wird nicht auf irgend etwas gewartet. Asynchron bedeutet, dass das Laden nicht die Webseite im Browser blockiert. Thomas schrieb: > Finde es nur schwer einen Java-Client (Darf auch ein C++ Client sein) zu > schreiben, der eine "Ajax"-Page anfragt und eben auch Javascript > ausführen kann. Er muss weder AJAX können noch JavaScript ausführen, er muss einfach periodisch GET/POST-Requests an den Server schicken und die Antwort auswerten.
Andreas Schwarz schrieb: > Die Anfrage wird beantwortet, so schnell es der Server kann, es wird > nicht auf irgend etwas gewartet. Asynchron bedeutet, dass das Laden > nicht die Webseite im Browser blockiert. das muss aber nicht sein. Ich habe selber eine Hausteuerung programmiert wo der Request einfach maximal 2min blockiert. Wenn ein Event kommt, dann wird er sofort beantwortet. Wenn nichts passiert sagt er nach 2 min das nicht los war. Der Client starten danach einfach die nächste Abfrage. Somit habe ich eine "Echtzeit" Rückmeldung an den Browser bei wenig Traffig und das einfach HTTP konform. Websockets find ich sehr umständlich auf der Server-seite zu programmieren.
Thomas schrieb: > Finde es nur schwer einen Java-Client (Darf auch ein C++ Client sein) zu > schreiben, der eine "Ajax"-Page anfragt und eben auch Javascript > ausführen kann. Äh.... ich glaub du hast da ein Verständnisproblem. AJAX ist nur eine Krücke welche es erlaubt aus JS asynchrone Anfragen an den Server zu stellen (was so normal nicht vorgesehen ist). In Java hast du das Problem doch überhauptnicht und kannst zu beliebigen Zeitpunkten eine Anfrage (nix anderes ist ein AJAX call) starten, z.B. über die URL Klasse (da muss man auch nix Handgestricktes nehmen!) da benötigt man kein Javascript für. Nebenbei kannst du in Android auch einfach einen BrowserFrame einbetten, wenn du dir den mehrfachaufwand sparen willst und für alle Endgeräte nur eine Website erstellen willst. Peter II schrieb: > wo der Request einfach maximal 2min blockiert http://en.wikipedia.org/wiki/Comet_%28programming%29 Frank schrieb: > Man kann den HTTP-Datenverkehr ja auch ordentlich abspecken HTTP hat nix mit Websites zu tun GET/POST/... sind HTTP was willst du da noch abspecken?
:
Bearbeitet durch User
Peter II schrieb: > Ich habe selber eine Hausteuerung programmiert > wo der Request einfach maximal 2min blockiert. Das kann man sich mit PHP u.ä. nur dann leisten, wenn man sehr wenige Clients hat die parallel zugreifen. > Websockets find ich sehr umständlich auf der Server-seite zu > programmieren. Schau dir mal websocketd oder die Ruby Websocket-Bibliothek an.
Andreas Schwarz schrieb: > Peter II schrieb: >> Ich habe selber eine Hausteuerung programmiert >> wo der Request einfach maximal 2min blockiert. > > Das kann man sich mit PHP u.ä. nur dann leisten, wenn man sehr wenige > Clients hat die parallel zugreifen. mit PHP geht das eh nicht sinnvoll. >> Websockets find ich sehr umständlich auf der Server-seite zu >> programmieren. > > Schau dir mal websocketd oder die Ruby Websocket-Bibliothek an. ich habe es direkt in meiner Applikation programmiert, da spare ich mir die ganze Interprocesskommunikation und kann direkt auf die Steuerung zugreifen. Es braucht genau die gleichen Resourcen wie ein WebSocket - jeweils ein offene Socket.
Ok so habe ich es nun auch gemacht. Einfach ein HTTP Request dessen Antwort einfach etwas länger dauert. Hatte Ajax wirklich mehr zugesprochen. Aber umso besser! So wirk das ziemlich einfach und es gibt keine großen Probleme. Ich dachte nur, dass die Serververbindung viel zu schnell abgebrochen wird. Wie oben schon festgestellt, wirkt sich ein sleep in einem PHP Skript nicht anscheinend nicht auf die Server-Timeout Zeit aus. So habe ich in meiner Endlosschleife einen sleep von 1sec eingebaut. Natürlich habe ich dann auch nur eine Abfrageauflösung von einer Sekunde, konnte jedoch einen Request über die ganze Nacht aufrecht erhalten. Geht bestimmt noch vieeeeel länger. Selbst wenn ich die Sleep-Zeit auf 250ms runterstelle. Dies gibt mir definitiv eine ausreichende Auflösung für die zyklische Abfrage von Daten auf dem Server. Frank schrieb: > Rolf Magnus schrieb: >> Muß es denn unbedingt http sein, wenn der Client eh kein Browser >> ist? > > Ist schon ok, denn damit hat man ohne viel Aufwand einen fertigen > Multi-Client-fähigen Server - ist schon verlockend. Den Aufwand einen eigenen Webserver aufzusetzen ist doch recht hoch. Habe schon mehrere eigene kleine Server implementiert. Es geht schon, jedoch bekommt man niemals so schnell so etwas hin, was mit den Fähigkeiten und Konfigurationsmöglichkeiten von Apache, PHP und MySql gleichkommt. Darum diesmal kein eigener Server. Rolf Magnus schrieb: > Muß es denn unbedingt http sein, wenn der Client eh kein Browser ist? Ein Typ der Clients wird ein Browser sein. Daneben PC, Mac, Linux und Android Applikationen. Andreas Schwarz schrieb: > Peter II schrieb: >> Ich habe selber eine Hausteuerung programmiert >> wo der Request einfach maximal 2min blockiert. > > Das kann man sich mit PHP u.ä. nur dann leisten, wenn man sehr wenige > Clients hat die parallel zugreifen. Mit wie vielen PHP Verbindungen kann ich denn rechnen? Ist das Einstellungssache? Wo könnte es noch zu Engpässen kommen? Vorerst gehe ich von einer Anzahl von maximal 5 Clients gleichzeitig aus. Es wird zwar viel mehr Clients geben, da ich jedoch derjenige bin, der die meisten davon nutzt, werden diese kaum gleichzeitig Verbunden sein.
Thomas schrieb: > Mit wie vielen PHP Verbindungen kann ich denn rechnen? Ist das > Einstellungssache? Wo könnte es noch zu Engpässen kommen? Das geht schon mit PHP, du must nur die Maximale Skriptlaufzeit anpassen und etwas mit dem Speicher schauen, ABER: Brauchst du wirklich eine Direktverbindung? Meist reicht pollen/auf Anfrage doch völlig aus, "Echtzeit" kannst du so eh nie erreichen. Bei paralleler Nutzung musst du eh im Server sicherstellen das es nicht zu Inkonsistenzen kommt und ggf. den User darüber informieren.
Läubi .. schrieb: > Brauchst du wirklich eine Direktverbindung? Meist reicht pollen/auf > Anfrage doch völlig aus, "Echtzeit" kannst du so eh nie erreichen. wenn er schon schreibt, das 1 Sekunde Verzögerung OK ist. Dann ist pollen doch keine sinnvolle Option. Jede Sekunde eine Request addiert sich auch schon im Traffic.
Peter II schrieb: > Dann ist pollen doch keine sinnvolle Option Wieso? Weil die Gefahr besteht, das sich der Server zu Tode langweilt?
Läubi .. schrieb: > Peter II schrieb: >> Dann ist pollen doch keine sinnvolle Option > > Wieso? Weil die Gefahr besteht, das sich der Server zu Tode langweilt? nein das die 200Mbyte Tarif schon nach 2 Tage verbraucht ist. Es ist einfach nicht sehr sinnvoll, jede Sekunde einen neue abfrage zu starten wenn es mit etwas nachdenken auch besser geht.
Peter II schrieb: > nein das die 200Mbyte Tarif schon nach 2 Tage verbraucht ist Welcher 200MB Tarif??? Wer sagt das er 24h am Tag davor hängt? Welche Datenmenge wird den hier tatsächlich übertragen? Man muss sich auch nicht immer was zusammenspinnen... Ob es "besser geht kannst du doch garnicht beurteilen, wenn sich die Daten alle 200ms ändern verursacht comet in diesem Fall 5x mehr Request. Und die "jede Sekunde ein Update" zweifel ich jetzt mal einfach eh als unnötig an. Denn entweder es ändert sich alle Sekunde was, dann hilft ja nun alles "nachdenken" nix, oder es ändert sich halt sehr viel seltener was, und ob das dann sind auch 5, 10, 20 ... Sekunden (oder sogar nur auf Anfrage) vollkommen ausreichend.
Läubi .. schrieb: > Peter II schrieb: > Denn entweder es ändert sich alle Sekunde was, dann hilft ja nun alles > "nachdenken" nix, oder es ändert sich halt sehr viel seltener was, und > ob das dann sind auch 5, 10, 20 ... Sekunden (oder sogar nur auf > Anfrage) vollkommen ausreichend. einfach Beispiel: Hausautomation dort wird er Status vom Licht angezeigt. Er ändert sich am Tag ein paar mal. Aber es greifen 4 Personen darauf zu. Jeder soll den aktuell Status sehen. Dort ist es sinnvoll "sofort" die Änderung anzuzeigen, auch wenn es sich selten ändert. Und ja wenn die Seite auf einem Handy läuft ist es durchaus möglich das sie am Tag 24Stunden offen ist (nicht zwangsläufig anzeigt wird)
Peter II schrieb: > Hausautomation dort wird er Status vom Licht angezeigt Und das muss ich jetzt quasi sofort sehen? Peter II schrieb: > Und ja wenn die Seite auf einem Handy läuft ist es durchaus möglich das > sie am Tag 24Stunden offen ist Ja wenn... lass ihn doch erstmal eine erste Basisversion hinkriegen. Den wenn das wirklich relevant ist, wäre ein Jetty-Server + Servlet viel einfacher, als PHP und Apache, der hat eingebauten Support für 'Continuations' und ist sehr viel flexibler für so eine Aufgabe insetzbar.
Läubi .. schrieb: > Peter II schrieb: >> Hausautomation dort wird er Status vom Licht angezeigt > Und das muss ich jetzt quasi sofort sehen? ja, weil es sonst nervig ist. > Den wenn das wirklich relevant ist, wäre ein Jetty-Server + Servlet > viel einfacher, als PHP und Apache, der hat eingebauten Support für > 'Continuations' und ist sehr viel flexibler für so eine Aufgabe > insetzbar. habe oben schon geschrieben, das PHP dafür nicht Ideal ist.
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.