>> Artikelansicht

RESTful Measurements

Teaser Der kommunikationskern der Anwendung ist ein Socketserver. Über diesen kommuniziert der Paspberry Pi mit seinen Clients im Netzwerk. Messdaten werden im internen Speicher (RAM) und bei Bedarf in einer NoSQL Datenbank (CouchDB) vorgehalten. Die Wahl auf einen Socketserver fiel, da er nicht an eine Programmiersprache gebunden ist, einfach zu implementieren und die Kommunikation direkt über sogenannte "HTTP REST" Anfragen ohne zusätzliche Software im Webbrowser ausgeführt werden kann. Auch können dadurch einfach Apps für Tablets oder Smartphones erstellt werden, ohne sich mit irgendwelchen Treibern für die verwendeten Messgeräte auseinandersetzen zu müssen. Da der Socketserver nicht auf den Standardport 80 hört, muss noch ein Proxyserver die Requests auf diesen Port umleiten. Im anderen Fall könnte man keinen Webserver auf Port 80 betreiben. Wer auf einen Webserver verzichtet, kann den Socketserver direkt auf Port 80 lauschen lassen. Da in unserer Anwendung jedoch auch ein Webserver vorgesehen ist, wird ein Apache-2.x eingesetzt, der durch das Modul mod_proxy gleich die Anpassung der Requests an den Socketserver auf Port 8080 weiterleitet. Mit dieser Konfiguration kann man jetzt Internetanwendungen direkt auf dem Raspberry Pi oder über das Netzwerk ausführen. Noch ein Wort zum Socketserver. Dieser erfüllt eine weitere wichtige Aufgabe im System. Denn nur er hat direkten Zugriff auf die Hardware und besitzt die entsprechenden Rechte.

Socketserver Diese Grafik veranschaulicht die Interaktion zwischen Webbrowser/Proxy/Socketserver. "foo" kann natürlich gegen einen aussagekräftigen Namen wie "datenlogger" ersetzt werden. Um die Variable a mit dem Wert 10 zu belegen, sendet man einfach > http://192.168.178.200/datenlogger/a=10 Wenn alles geklappt hat, erhält man als Antwort "ok". Um den Wert der Variablen a wieder auszulesen, sendet man > http://192.168.178.200/datenlogger/a=?

Geht es auch ohne Proxy?

Die Frage ist berechtigt, und hier kommt auch schon die Antwort: "ja". Programmiersprachen wie Python, Perl, Ruby oder Php etc. bieten den direkten Zugriff auf Sockets an. So kann man zum Beispiel ganz einfach eine Brücke zwischen dem Socketserver und Php herstellen, indem man direkt mit dem Socketserver kommuniziert. Der Vorteil dieser Technik ist auch, dass auf der Kommandozeile im Raspberry Pi (per ssh) das entsprechende Script ausgeführt werden kann oder vom Webserver (falls vorhanden) über cgi erreichbar ist. Diese Technik ist zu bevorzugen, wenn man eine Applikation für den Raspberry Pi in einer dieser Programmiersprachen erstellt, da dies der direkte Kommunikationsweg zu den Messgeräten ist, ohne dass die Applikation root-Rechte benötigt. Vom Webbrowser aus erreicht man den Socketserver direkt, indem man den Port mit angibt. > http://192.168.178.200:8080/a=10

Warum dann der ganze Aufwand?

Das liegt an einem Sicherheitsmechanismus im Webbrowser, der besagt, dass ein Zugriff von einer Webseite immer vom gleichen Speicherort(Origin) kommen muss. Wenn unsere Webseite auf dem Port 80 läuft, wird ein Zugriff per JavaScript/Ajax auf Port 8080 geblockt. Aber ein ganz wichtiger Punkt, um leistungsfähige und interaktive Applikationen auf dem Client laufen zu lassen, ist die Verwendung von JavaScript/Ajax. Mehr Informationen erhält man hier [http://de.wikipedia.org/wiki/Same-Origin-Policy] Weitere Möglichkeiten der Umgehung des Problems und dessen Einschränkungen (CORS) sind hier einzusehen [http://de.wikipedia.org/wiki/Cross-Origin_Resource_Sharing]. Zu guter Letzt sei auch darauf hingewiesen, dass der Socketserver über JSON kommuniziert und somit, wenn man sich auf GET-Anfragen beschränkt, JSONP verwendet werden kann. Siehe: [http://de.wikipedia.org/wiki/JSONP#JSONP] Auch kann der Socketserver spezielle Header senden. (CORS)

Was ist mit WebSockets?

Für WebSockets kann der Socketserver direkt in den WebSocket Modus umgeschaltet werden. Das hat den Nachteil, dass einige Webbrowser und auch Smartphones/Tablets noch nicht mit WebSockets zusammenarbeiten können. Für die Zukunft sind WebSockets jedoch zu bevorzugen, sobald WebSockets weiter verbreitet sind. Alternativ kann man auch einen zusätzlich WebSocket Server starten, der die Kommandos an den Socketserver durchreicht. Weitere Informationen zu WebSockets kann man hier nachlesen [https://developer.mozilla.org/en-US/docs/WebSockets]

nächster Artikel