nicht angemeldet
Erfahrung mit Embedded Webserver
Ha, jetzt habe ich auch mal eine Frage!
Hallo Kollegen,
ich habe ein seeehr ungewöhnliches Web-Projekt aufgesetzt, dass ich Euch (umständehalber) leider nie zeigen kann :-)
Also: Ich habe heute einen Embedded Webserver unter dem (Realtime-, Multitasking-) Betriebssystem EUROSplus 3.19 (kennt ganz sicher niemand von Euch) zum Laufen gebracht. Nachdem ich kein File-System installieren will, werden alle "Webseiten" volldynamisch und online per C++ generiert. Ziel ist es, einigermaßen performant alle möglichen Informationen zwischen dem Web-Client und der Maschine mit dem Web-Server (Messwerte, Variablenwerte, Stati, Events) auszutauschen.
So weit, so gut. Funktioniert auch ganz prima. Langsam erahne ich, welche Potentiale hinter dieser Art eines HMI verbergen. Leider ist die Literatur in diesem Bereich extrem dünn. Hat jemand von Euch mit dem Thema Erfahrung? An welcher Stelle lässt sich der HTTP-Protokollverkehr beschleunigen? Kann ich auf _einen_ HTTP-Request _mehrere_ (viele, unendlich viele) HTTP-Responses folgen lassen? Wie kann ich mehr als einen Request pro Sekunde vom Web-Browser generieren (<meta http-equiv="refresh" content="0,2 ... wird wohl kaum gehen). Wer hat schon mal eine Web-Browser/Client Kombination zu Debug-Zwecke eingesetzt? Wer hat Ideen für eine pfiffige Darstellung der Informationen (z. B. viele, viele iFrames, um die Datenmenge zu minimieren? Wie kann ich auf Web-Basis ene Art Terminal-Server/Client Kombination implementieren? Etc, etc, ...
Im Internet ist rein gar nichts zu derlei Fragen zu finden. Nur irgend welche Firmen, die eine fertige Lösung vrkaufen wollen, mit denen ich nichts anfangen kann.
Ciao
Hans-Peter
-
Hi,
ich habe ein seeehr ungewöhnliches Web-Projekt aufgesetzt,
So ungewöhnlich scheint es nicht zu sein. Da bei mir bei "EUROSplus" zwar irgendetwas klingelte, ich aber nicht mehr genau wußte, was genau, habe ich getan, was viele von uns in der gleichen Situation getan hätten: Google gefragt.
Lustigerweise ist gleich auf der erstens Seit etwas weiter unten folgender Link: http://www-et.bocholt.fh-gelsenkirchen.de/~juen/ak_tele/ak_tele4.html
Ganz unten auf der Seite sind ein paar Projekte gelistet. Blöderweise ist genau das erste verstorben. Und ich nehme mal an, das Dein Projekt etwas mit M&R zu tun hat, oder?dass ich Euch (umständehalber) leider nie zeigen kann :-)
Ja, komm, nimm doch mal in die Hand und mach' ein Photo. Wirst damit schon keine Geschäftsgeheimnisse verraten ;-)
Hat jemand von Euch mit dem Thema Erfahrung? An welcher Stelle lässt sich der HTTP-Protokollverkehr beschleunigen?
Du meinst in den Schedule einpassen? Realtime hat ja nix mit rohem Speed zu tun, aber das muß ich Dir ja wohl nicht erzählen, oder? ;-)
Kann ich auf _einen_ HTTP-Request _mehrere_ (viele, unendlich viele) HTTP-Responses folgen lassen?
Klar kannst Du das, wenn der Client mitspielt.
Wie kann ich mehr als einen Request pro Sekunde vom Web-Browser generieren (<meta http-equiv="refresh" content="0,2 ... wird wohl kaum gehen).
"Dig the code!" ist wohl kein guter Vorschlag, hierfür jedoch unumgänglich.
Wie kann ich auf Web-Basis ene Art Terminal-Server/Client Kombination implementieren? Etc, etc, ...
Nein, nicht "etc", genau das mit der Terminal-Emulation via Browser ist Dein Problem. Wenn Du Dir das mal als "Chat" vorstellst und Dich erinnerst, was auch Du den Leuten sagen würdest, die fragen, wie man sowas nur mit HTML und evt noch ein wenig Javascript realisieren könne. Genau: "Datt funktioniert nich'!". Vielleicht könntest Du mit xmlHttpRequest() spielen, wäre die einzige Möglichkeit.
Ach, jetzt habe ich sie schon gelöscht, die Frage nach der UI. Ist ein wenig schlecht zu beantworten, wenn man über die gelieferten Daten so rein gar nix weiß. Es ist jedoch zu empfehlen, keine Abbilder von echten Anzeigen und Bedienelementen zu erstellen, die sind bei einer Programm-GUI nur selten nützlich, meist jedoch schädlich.
Im Internet ist rein gar nichts zu derlei Fragen zu finden. Nur irgend welche Firmen, die eine fertige Lösung vrkaufen wollen, mit denen ich nichts anfangen kann.
Es ist halt einfach ein zu kleiner Markt im Hobbybereich, während es jedoch einen riesigen kommerziellen Markt dafür gibt. Das meistverbreitete Betriebsystem ist ja schließlich TRON, ein RT-OS das auf allem oberhalb eines Abacus' läuft ;-)
Aber ein sehr schönes Projekt, das Du da hast, mich packt der Neid, der giftig-gelbe! :-)
so short
Christoph Zurnieden
-
Ziel ist es, einigermaßen performant alle möglichen Informationen zwischen dem Web-Client und der Maschine mit dem Web-Server (Messwerte, Variablenwerte, Stati, Events) auszutauschen.
An welcher Stelle lässt sich der HTTP-Protokollverkehr beschleunigen?
An der Generierung der Daten, vielleicht beim Datentransport (Komprimierung). Das eigentliche Protokoll umfasst so wenig Daten so knapp formuliert, das lässt sich nicht beschleunigen.
Kann ich auf _einen_ HTTP-Request _mehrere_ (viele, unendlich viele) HTTP-Responses folgen lassen?
Nein, eine Anfrage, eine Antwort.
Wie kann ich mehr als einen Request pro Sekunde vom Web-Browser generieren (<meta http-equiv="refresh" content="0,2 ... wird wohl kaum gehen).
Javascript, window.setInterval.
Wer hat Ideen für eine pfiffige Darstellung der Informationen (z. B. viele, viele iFrames, um die Datenmenge zu minimieren?
Mit "viele, viele iFrames" treibst du bestenfalls den Browser zum Wahnsinn und noch vorher den Anwender zur Verzweiflung.
Wie kann ich auf Web-Basis ene Art Terminal-Server/Client Kombination implementieren?
Wenn du einen Terminaldienst haben willst, warum nimmst du keinen Terminaldienst? HTTP ist für Pushdienste von Haus aus und erst recht im Zehntelsekundenbereich wie sie dir vorschweben nicht geeignet. Ständiges Pollen ist wie überall auch bei HTTP die denkbar schlechteste Möglichkeit, Daten auf dem aktuellen Stand zu halten.
Entwickle dein eigenes Protokoll, und wenn du einen Webbrowser benutzen willst, verwende ein Java-Applet. -
Hallo,
danke für die Antworten, jetzt bin ich schon ein kleinwenig weiter. Die HTTP-Schnittstelle ist eigentlich ei reiner Nebenkriegsschauplatz (aber ein hübscher) und macht vielleicht 3% vom Gesamtprojekt aus. Eigentlich soll ich ja ein System steuern :-)
Danke und Ciao
Hans-Peter