Dokumentation Mini-Telnet V

Transkript

1 Dokumentation Mini-Telnet V Programm von Malte Klas und Fabian Reynolds Weitere wichtige Hinweise stehen in den Readmes in den jeweiligen Ordnern! Inhalt: 1. Konzept 1. Vorlagen 2. Problemstellung 2. Bedienung und Funktionsweise 1. Bedienung Server 1. Oberfläche 2. Bedienung Client 1. Oberfläche 3. Beschreibung der Klassen 1. Server 2. Client 4. Steuerbefehle

2 1. Konzept 1. Vorlagen Das Programm sollte ursprünglich ein Chat-Server/Client werden, der jedoch aufgrund der geringen Herausforderung schnell verworfen wurde. Dieser Prototyp basierte im Grunde auf SuM-Bibliotheken, verwendete aber eine javax.swing-/java.awt-oberfläche. Er war zugegebenermaßen recht eng an der Vorlage im SuM-Kurs III, was unter anderem auch den Themenwechsel begründete. Im Weiteren orientiert sich das Programm teilweise leicht an einem von einigen Freunden entwickelten Chat-Server/Clients, der wiederum eine stark abgewandelte und umfassend erweiterte Version des SuM-Musterprogrammes war. Aus diesen Programmen stammen allerdings nur Anregungen und Ideen, das Programm wurde komplett selbstständig geschrieben. 2. Problemstellung Im Prinzip ist die Ausgangssituation ähnlich der Situation, die zur Entwicklung von telnet/ssh/rsh beziehungsweise in neuerer Zeit RDP/VNC führte: Auf einem entfernten Rechner im Netzwerk muss eine Aufgabe erledigt werden, der Systemstatus muss kontrolliert werden (Anmerkung Malte: Meinem Bruder muss das Internet wegen zu langsamer Download-Raten gekappt werden...) etc. Wenn man jetzt ein Programm hat, das aus dem Netzwerk Befehle entgegennimt, dann lassen sich solche Sachen bequem vom Sofa aus erledigen, ohne dafür aufstehen zu müssen. Das Programm muss also Clients aufnehmen, diese eventuell überprüfen (oder auch nicht ) und dann Befehle von diesen ausführen können. Um vor allzu leichtem Missbrauch zu schützen, wäre die Unterstützung einer Whitelist beziehungsweise Blacklist lohnenswert.

3 2. Bedienung und Funktionsweise 1. Bedienung Server 1. Oberfläche Statusfenster Die Oberfläche besteht hauptsächlich aus einem einzigen Kontrollfenster: Startet den Server Hauptserver-Port Beendet das Programm Bildserver-Port Ungewollte Nutzer kicken Bildserver-Port automatisch bekanntmachen Hartnäckige Spammer etc. bannen Platz schaffen... (Bild des Serverfensters nach Start des Severs) Die unteren Schaltflächen können nur nach Start des Servers benutzt werden. Dabei werden die Startschaltfläche, die Portfelder und die Kontrollbox für den ImgPort deaktiviert. Sämtliche sonstigen Dialoge sind (hoffentlich) selbsterklärend. Der Server kann über die Dateien whitelist.txt und blacklist.txt angewiesen werden, bestimmte IP-Adressen ohne Bestätigung zu aktzeptieren (Whitelist) oder zu blocken (Blacklist). Dazu müssen die Adressen in die jeweiligen Dateien eingetragen werden. Hinweis: Bannen im laufenden Betrieb verändert die Dateien nicht! Pro Zeile darf maximal eine IP stehen, Kommentare etc. sind nicht erlaubt (und könnten zu Abstürzen führen!).

4 2. Bedienung Client 1. Oberfläche und Befehle Der Client wird ebenfalls über ein zentrales Fenster gesteuert: Meldungsfeld Eingabe der Serverdaten (Port des Hauptservers) Kommandozeile Kommando senden Client starten Schluss... Die Kommandos müssen auf dem Server ausführbar sein (Programme), bei Skripten ist der Interpreter aufzurufen, um sie ausführen zu können. Bsp.: Die meisten Programmstarter starten auch fest verknüpfte Dateien (z.b. ein Bild, das mit dem Webbrowser verknüpft ist), da das aber nicht auf allen Plattformen unterstützt wird, ist das in der von uns verwendeten Java-Methode nicht erlaubt. Das Gleiche gilt ähnlich für Dos-Befehle: dir geht nicht, cmd.exe /C dir geht. Hinweis: Der Befehl getscreen ist ein Sonderbefehl, er wird nicht auf dem Server ausgeführt, sondern zeigt einen Screenshot des Servers an. Durch getscreen <bla>.png wird der Screenshot direkt in eine Datei gespeichert! Der Client hat eine Datei mit dem Namen cli.conf, in der der Standartport und -server eingetragen sind. Bei häufigem Benutzen eines Servers empfiehlt es sich, diese Datei entsprechend anzupassen. Sollte die Datei nicht vorhanden oder lesbar sein, stellt sich der Client automatisch auf Der Port für den Bildserver ist nicht konfigurierbar, er wird entweder automatisch empfangen oder ist nicht verfügbar. Durch die Sperrung der Bilder lässt sich so unter anderem die Netzwerklast senken. PS.: Viele Diagnose/Debugmeldungen werden nur auf der Konsole ausgegeben ( java -jar... ). In diesem Fall sollte dringend der Befehl malte ausgeführt werden ;).

5 3. Beschreibung der Klassen 1. Server ISWYAD.java Dies ist die Haupklasse des Servers. Sie enthält die (Haupt-)Mainmethode, die nichts anderes tut als ein neues StatWin -Objekt zu erzeugen und bei diesem die von JFrame geerbte Methode setvisible(true) mit aufzurufen. CmdWin.java Das ist die (aus Zeitgründen mit Netbeans (GUI) erstellte Klasse für die Benutzeroberfläche. In ihr wird außerdem ein Teil der weiterführenden Befehle aufgerufen (z.b. die Serverklasse instanziert usw.). Die Methode addtxt(string) ist neu und fügt eine neue Zeile im Meldungsfenster hinzu. Svr.java Diese Klasse, die vom SuM-Server abgeleitet ist, regelt den textbasierten Austausch zwischen Client und Server. In ihr werden alle Befehle der Clients verarbeitet und vor allem verwaltet (kicken, bannen, bearbeiten...). Durch Verwendung der SuM- Biblithek ist der grundlegende Aufbau sehr einfach: Es sind alle nötigen Ereignisse schon als Methoden definiert, die nur noch überschrieben werden müssen ImgSvrThread.java Die Bezeichnung ist eigentlich nicht ganz passend, da laut den offiziellen Java- Tutorials mit *Thread eigentlich bei mehreren Clients die für jeden Client erzeugten Threads gemeint werden, in diesem Programm aber nur ein Bild nach dem anderen geladen werden kann, um den Server bei geringer Bandbreite nicht unnötig zu überlasten. Nichtsdestotrotz ist der ImgSvrThread ein eigener Thread, um den eigentlichen Server möglichst weiter handlungsfähig zu halten. Er basiert auf dem Standart-Socket aus java.net und schreibt das Bild mit Hilfe von ImageIO in den durch den Socket erzeugten Stream. Das wäre mit SuM-Methoden zwar auch möglich gewesen (Überschreiben der Funktion read() des Streams mit einer modifizierten sendeaneinen(string) -Methode oder so...), hat aber in der Praxis zu massiven Problemen geführt (Streams kamen nicht an, hörten nicht auf etc.). ListReader.java Klasse zum komfortablen Lesen der Blacklist/Whitelist mit einem BufferedReader. KickHim.java, BanHim.java, AllowNewConnection.java Kleinere Dialogfenster, die eigentlich selbsterklärend sein sollten.

6 2. Client ISWYADCli.java Die Hauptklasse des Clients, siehe oben. CmdWin.java Das ist das Hauptfenster des Clients, das außer ImgShow das einzige Fenster ist. Es wird in der Hauptklasse erzeugt und enthält im Prinzip einen Großteil des Programms beziehungsweise ruft diesen aus anderen Klassen auf. Es ist auch für das Erzeugen eines ConfReader zuständig und liest mit diesem die Standartwerte für den Server. Wieder ist zum einfachen Textausgeben eine Funktion addtxt(string) implementiert. Cli.java Diese Klasse basiert auf der SuM-Klasse Clientverbindung und enthält alles, was mit Datenaustausch auf Textebene zu tun hat. Sie wird von CmdWin aus gestartet und verarbeitet auch Steuerbefehle. Die Bilddaten werden wieder in einer eigenen, nach Bestätigung vom Server instanzierten Klasse gestartet. ImgCli.java Mit dieser von Cli aufgerufenen Klasse werden Bilddaten vom Server verarbeitet, formatiert und eventuell in eine Datei geschrieben. Das alles geschieht mit Hilfe von ImageIO und Socket. ConfReader.java Diese Klasse sorgt (wie ListReader beim Server) für das einfache Lesen der Konfigurationsdatei, die den Standartserver enthält. ImgShow.java Das ist ein einfaches JFrame, das ein JLabel enthält, um das vom Server gesendete Bild als ImageIcon anzeigt. Dazu ist die Methode getjlabel() implementiert. AsciiArt.java Einfach den Client aus der Kommandozeile aufrufen und malte eingeben Steuerbefehle Client und Server kommunizieren mit Steuerbefehlen, die mit $ anfangen und groß geschrieben werden. Dadurch wird zum Beispiel ein Bild gefordert ( $SCRGET ) oder der Bildserverport festgelegt ( $IMGPRT<xxxxx> ). Es ist nicht geplant, dass diese Befehle von Hand eingegeben werden, kann theoretisch aber gemacht werden (was seltsame Reaktionen hervorrufen könnte). Diese Befehle werden im Client nicht und im Server nur teilweise angezeigt. Statt dieser Befehle sollten Bilder nur mit getscreen [eventuell Dateiname] ( siehe oben, 2.2.1) geladen werden!