Hallo in die Runde! Für ein neues Projekt soll unterschieden werden zwischen einem Run Modus und einem Setup Modus. Einfachste Variante wäre über einen Schalter. Ist es möglich, die Unterscheidung zu treffen anhand der Frage "Hängt an der Ethernetschnittstelle gerade ein Webbrowser?" - dann soll ein Webserver zum Setup starten. Anderenfalls in den Run-Modus verzweigt werden. Gibt es Strategien, die Gegenseite einer Ethernetschnittstelle auszuwerten?
Sowas ist in Linux/Unix ein Standardverfahren für Netzwerkdienste, über inetd und Verwandte. Der Service inetd hängt am Port und startet ein Server-Programm, sobald jemand darauf zugreift. Der reine Start eines Browsers ohne Seitenzugriff ist nur auf dem betreffenden Rechnet selbst feststellbar, sofern der nicht irgendwelche Autostarts hat (Update, Proxy-Suche, Statistik, Startseite, ...).
Peter Müller schrieb: > Ethernetschnittstelle gerade ein Webbrowser Du vermischst verschiedene Ebenen des OSI-Modells. Nach der Ethernet-Verbindung hast Du noch IP und TCP/UDP und dann kommt erst der Webserver. Um welche Umgebung handelt es sich? Kannst Du die Aufgabenstellung konkretisieren?
Der Web Server kann keine Verbindung zu einem Browser aufbauen. Ergo kann er nicht wissen, ob ein Browser verfügbar ist. Du kannst höchstens erkennen, ob der Computer, auf dem der Browser erwartet wird, erreichbar ist (mit Ping).
Hallo, das ist ein grundsätzliches Problem: ein Browser baut keine Verbindung auf und hält sie aufrecht, sondern fordert eine Seite an und das wars - wenn du nach dem Browser fragst, kann der User schon wo ganz anders sein, und er meldet sich nie wieder. Georg
Peter Müller schrieb: > Ist es möglich, die Unterscheidung zu treffen anhand der Frage "Hängt an > der Ethernetschnittstelle gerade ein Webbrowser?" - dann soll ein > Webserver zum Setup starten. Anderenfalls in den Run-Modus verzweigt > werden. Nein, das ist weitgehend unmöglich und zwar deshalb, weil es praktisch schon unmöglich ist, festzustellen, ob überhaupt ein Peer vorhanden ist, mit dem man kommunizieren könnte. Alles, was man ziemlich sicher feststellen kann, ist der Status auf Link-Level. Der sagt allerdings auch schon "Peer vorhanden", wenn dein Gerät als einziges an einen dummen Switch oder Hub angeschlossen ist, also weit und breit nix ist, mit was man tatsächlich reden könnte. Aber selbst, wenn man mal (per Axiom) voraussetzt, dass das angeschlossene Gerät kein Switch/Hub, sondern immer ein Computer ist, bist du auch noch keinen Schritt weiter. Denn du kennst dann trotzdem noch nichtmal seine MAC-Addresse, geschweige denn seine IP. Du müsstest also ein weiteres Axiom einführen, nämlich die (durch nichts begründete) Annahme, dass auch das gegnerische Gerät über die Schnittstelle dringend kommunizieren will und deshalb die Etablierung eines Links zum Anlass nimmt, DHCP-Broadcasts über diesen Link zu senden. Dann allerdings bist du einen Riesenschritt weiter, denn du kennst jetzt die MAC des Peer. Und wenn der Peer eine Schlampe und deshalb wenig wählerisch bei der Wahl seiner Kommunikationspartner ist, wird er vielleicht sogar eine DHCP-Antwort von dir akzeptieren, dann kennst du sogar seine IP, weil du ihm die selber zugeteilt hast. Alles, was du bis hierher machen mußt: Einen DHCP-Server auf deiner Kiste laufen lassen. Schon gewonnen? Nein, natürlich noch längst nicht. Wenn der Peer mehrere Netzwerkschnittstellen hat und eine andere bereits vorher verbunden war, wird er in der Regel nicht seine default route auf "deine" Schnittstelle legen. Also ist schon wieder das nächste Axiom fällig: der Peer darf entweder nur eine aktive Netzwerkschnittstelle haben oder muß bereit sein, freiwillig die default route auf jedes neu auftauchende Interface zu legen. Das wird jetzt aber schon sehr unkonventionell, nur Vollidioten würden ihre Rechner derart konfigurieren und genau die wären garnicht dazu in der Lage, dies zu tun... Aber weiter mit dem neuen Axiom. Jetzt gewonnen? Nein, natürlich immer noch nicht. Du weisst immer noch nicht, ob auf dem Peer ein Browser läuft und du hast auch keine Möglichkeit, das durch irgendwelche Tricks aktiv herauszufinden. Du müßtest warten, bis der Browser von sich aus irgendwas tut. I.d.R. wäre bei einem neuen Interface das erste Anzeichen dafür, daß er einen DNS-Request macht. Du müßtest also auch noch einen DNS-Server laufen haben, der jeden Request zu deiner eigenen IP auflöst, denn nur mit so einer Antwort käme der Browser das erste Mal auf die Idee, einen (mehr oder weniger) browsertypischen Request zu senden, an dem du dann letztlich (mit recht geringer Zuverlässigkeit) erkennen könntest, dass auf dem Peer ein Browser läuft...
Hey, danke allen für die Beiträge! Hatte mir Ähnliches schon gedacht, aber manchmal fühlt man sich ja doch besser, wenn man eine Idee mal in der Runde ausgeboxt hat, wie hier geschehen :-) Danke insbesondere an c-hater, für die detaillierte Darlegung! Einen schönen Abend!
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.