Dokumentation. Forschungsprojekt Virtueller Seminarraum 2. Simona Empoli Sylvana Kroop

Transkript

1 Dokumentation Forschungsprojekt Virtueller Seminarraum 2 Betreuung: Prof. C.A. Wüthrich Simona Empoli Sylvana Kroop Marion Kulig Matrikelnummer: Studiengang Mediensysteme Bauhaus-Universität Weimar Fakultät Medien 1

2 Inhaltsverzeichnis 1. Einleitung Möglichkeiten des File-Sharings Datenbank Peer-to-Peer Client/Server Client/Server Architektur Grundlagen Der Client Der Server Der Fileserver Serialisierung ViSe Client/Server Modell Der Fileserver Recherche Funktionalitäten Der Fileserver für ViSe Das Programm Der Quellcode Der Client Der Server Der ChannelWorker Der FileService Message Der Test Die Ausführung Ausblick Quellenverzeichnis Anhang

3 1. Einleitung Im Wintersemester 02/03 begann die Implementierung eines Virtuellen Seminarraums im Rahmen von medienquadrat. Medienquadrat ist ein Projekt, welches neue Lernmedien und werkzeuge für projektorientiertes vernetztes Studieren erarbeitet. Der Virtuelle Seminarraum stellt eine Kommunikationsplattform dar, die sich nicht nur auf einige Funktionalitäten, wie zum Beispiel Videokonferenz und Chat, beschränkt, sondern die umfassend alle Möglichkeiten integrieren soll, die E-Learning unterstützt. Nach Beendigung des ersten Semesters (02/03) existierten unter anderem ein Chat, ein Whiteoard mit eingeschränkten Funktionalitäten und ein Authenticator, der für die zukünftige Rechteverwaltung verwendet werden sollte. Uns stellte sich somit die Aufgabe diese Plattform mit ihren Funktionalitäten zu erweitern. Nachdem diverse Vorträge, rund um das Thema Online lernen gehalten wurden, wobei sich meiner mit Experimentellen Forschungsmethoden im Bereich der Wahrnehmung/Usability beschäftigte, begann die Arbeit der Projektteilnehmer an ihren jeweiligen Bereichen. So war meine Aufgabe die Implementierung einer Möglichkeit zur Dateispeicherung. Dabei stellte sich heraus, dass ein zentraler Fileserver den Ansprüchen am besten gerecht werden könnte, nachdem auch Peer-to-Peer und Datenbanksysteme auf ihre Tauglichkeit hin überprüft wurden. Diese Dokumentation widmet sich zu einem größeren Teil angeeignetem theoretischen Wissen, um für Nachfolger einen leichteren und kürzer dauernden Einstieg zu ermöglichen. Es wird allgemein erläutert, welche Möglichkeiten des File- Sharings existieren und in Betracht gezogen wurden. Nachdem ein Fileserver als eine passende Lösung gefunden wurde, wird die Funktionsweise eines solchen Client/Server-Systems unter Verwendung von Java kurz erklärt. Danach folgt eine Spezifizierung bezüglich des Fileservers und dessen Grundfunktionalitäten. 3

4 Das Programm, welches danach vorgestellt wird, zeigt, wie der Dateitransfer in ViSe funktionieren kann. Die verwendeten Quellen befinden sich zum einen in den entsprechenden Kapiteln und im Quellenverzeichnis. Im Anhang ist außerdem eine komplette Übersicht über die Klassen in Form von UML-Darstellungen vorhanden. 4

5 2. Möglichkeiten des File-Sharings Die erste Aufgabe war, herauszufinden, in welcher Art und Weise ein File-Sharing- System realisiert werden könnte. Dabei bin ich auf drei Möglichkeiten gestoßen, die nachfolgend vorgestellt werden Datenbank Eine Datenbank ist eine Sammlung von Daten, die organisiert und einem bestimmten Zweck dienend abgespeichert sind. Dabei ist es aber schwieriger, bzw. umständlicher den Zugriff mithilfe einer Datenbank auf Dateien zu ermöglichen. Diese müssten ja wiederum irgendwo abgespeichert, um dann katalogisiert zu werden. Deshalb löst eine Datenbank nicht das eigentliche Problem des File-Sharings, sondern stellt eine Möglichkeit bei Existenz eines solchen Systems dar, dieses zu erweitern. Bei sehr großem Datenvolumen und Unwissen darüber, wo sich welche Dateien befinden, ist es sinnvoll an eine Datenbank zu denken. In unserem Fall spielt sie fürs erste keine Rolle Peer-to-Peer Peer-to-Peer ist die älteste Form der Vernetzung von Computern. Es sind alle Stationen gleichberechtigt. Quelle: fcit.coedu.usf.edu/network/ chap6/chap6.htm 5

6 Für ViSe würde das bedeuten, dass die zur Verfügung stehenden Dateien dezentral bei den Nutzern liegen. Dafür das diese Möglichkeit nicht verwendet wurde, sprechen mehrere Gründe: - Um auf die Dateien eines bestimmten Rechners zuzugreifen, muss der jeweilige Nutzer online sein. Sobald der Rechner ausgeschaltet wird, ist kein Zugriff mehr möglich. - Entweder muss der anfordernde Nutzer wissen, welche Datei er braucht, oder es muss eine Übersicht existieren, die regelmäßig aktualisiert wird, in der alle zur Verfügung stehenden Dateien aufgelistet sind. Dieses sollte ein größeres Problem darstellen, da die Anzahl der Nutzer sich so schnell ändern kann, sodass es arge Synchronisationsprobleme geben könnte. - Die Zeitdifferenz der Aktualisierung muss dementsprechend gering sein. Dies könnte einen zu hohen Rechenaufwand bedeuten. - Schon wenn die Anzahl der Nutzer die 10 erreicht, ist die Zeit die für das Suchen einer Datei benötigt wird, für den Sucher inakzeptabel. Zu jedem Rechner müsste die Verbindung aufgebaut werden, der entsprechende Ordner durchsucht werden und bei finden der Datei diese übermittelt werden. Bei Nichtauffinden schreitet die Suche fort. In den Nachteilen von Peer-to-Peer-Netzen liegen gleichzeitig die Vorteile von Client- Server-Systemen. Peer-to-Peer-Netzwerke sind langsamer als solche, die auf einem Server basieren. Wenn sich viele Peer-Rechner gleichzeitig Daten einander zukommen lassen wollen, lässt die Leistung des Netzes deutlich nach. Client-Server- Systeme liegen immer dann vorn, wenn eine hohe Verarbeitungsgeschwindigkeit gefordert ist, was bei ViSe zutrifft. Für die Recherche waren unter anderem folgende zwei Links hilfreich: - Peer-to-Peer mit JXTA - 6

7 2.3. Client-Server In einem Client/Server System werden bestimmte Aufgaben auf einen Server ausgelagert, der auf diesen Aufgabentypus spezialisiert ist. Das führt zu einer besseren Auslastung. Schlussendlich wurde sich für solch eine Struktur entschieden. 7

8 3. Client/Server - Architektur 3.1. Grundlagen Nachfolgend werden die programmiertechnischen Konzepte eines Client/Server- Systems, wie sie in Java verwendet werden, kurz vorgestellt Der Client Die Netzwerkkommunikation findet mithilfe von Sockets statt. Ein Socket ist eine streambasierte Programmierschnittstelle, die für die Kommunikation zweier Rechner notwendig ist. Für die Erzeugung stehen Konstruktoren zur Verfügung. In diesen werden der Hostname und der Port als Argumente übergeben. Mit den beiden Methoden getinpustream und getoutpustream kann nach erfolgreichem Verbindungsaufbau jeweils ein Stream zum Versenden und Empfangen von Daten bereitgestellt werden Der Server Für den Verbindungsaufbau serverseitig steht die Klasse ServerSocket zur Verfügung. Deren Methoden warten auf Verbindungsanfragen und geben nach dem Verbindungsaufbau einen Socket zur Kommunikation mit dem Client zurück. Wesentlich hier sind der Konstruktor und die Methode accept(). Der Konstruktor erzeugt einen ServerSocket für einen bestimmten Port (Typ von Serveranwendung). Danach wird mit accept() auf eine Verbindungsanfrage gewartet. Bis ein Verbindungsversuch eines Clients gemacht wird, ist accept() blockiert. Wenn die Anfrage erfolgt ist, kann mit einem anderen Client durch ein Socket-Objekt, welches durch accept() zurückgeschickt wird, kommuniziert werden. 8

9 - - Seminar über Java- Sockets, ein Einstieg Bietet einen ersten Überblick bezüglich der Netzwerkproblematik Der Fileserver Als Grundlage bietet Java ein ausführliches Datei- und Verzeichnishandling an, wie z.b. den Zugriff auf Teile des Pfadnamens oder auf Verzeichniseinträge. Aus den beiden Methoden getinputstream und getoutputstream sind einige weitere Klassen abgeleitet, wie die hier benötigten FileInpustream und FileOutputStream. So stellt FileInputStream einen Byte-Stream zum Lesen aus einer Datei zur Verfügung. Genauere Erklärungen folgen anhand des Programms im hinteren Teil der Dokumentation Serialisierung Für die Übertragung von Objekten gibt es in Java die Möglichkeit der Serialisierung. Darunter wird hier die Fähigkeit verstanden, Objekte, die im Hauptspeicher der Anwendung existieren, in ein Format zu konvertieren, das es erlaubt, die Objekte in Dateien zu schreiben oder über eine Netzwerkverbindung zu transportieren. Der umgekehrte Weg wird mit eingeschlossen. Dafür gibt es im Paket java.io die Klasse ObjectOutputStream. Diese besitzt einen Konstruktor, der einen OutputStream als Argument erwartet. Der Stream dient als Ziel der Ausgabe. Um die serialisierten Daten in eine Datei zu schreiben, wird hier ein FileOutputStream verwendet. Damit ein Objekt serialisiert werden kann, muss es lediglich das Serializable - Interface implementieren. 9

10 3.2. ViSe Client-Server-Modell Zusätzlich zum Server und zu den Clients besteht das ViSe -System aus einem weiteren dritten Komponenten - den Pseudo-Clients. Diese werden vom Server wie normale Clients behandelt, implementieren aber alle Funktionen von ViSe, wie die Rechteverwaltung und das Whiteboard. Somit hat der Server die alleinige Aufgabe, empfangene Daten weiterzuleiten. Diese Weiterleitung erfolgt in ViSe mit Messages. Diese Java Objekte enthalten Informationen zur Art der Nachricht (Header, Absender, Empfänger, Inhalt). Der Inhalt wird durch ein Datenobjekt dargestellt. Anhand des Headers entscheidet der Server, an welche (Pseudo-)Clients die Nachricht weitergeschickt werden soll. Dazu besitzt er eine Abonnement-Liste, in der alle (Pseudo-)Clients enthalten sind, die die entsprechende Message Art abonniert haben. Über den Inhalt muss der Server keine Kenntnis haben. 10

11 4. Der Fileserver 4.1. Recherche Um einen Einstieg und einen ersten Überblick in die Implementierungsmöglichkeiten zu finden, wurde ausgiebig nach bereits vorhandenen Ansätzen gesucht. Nachfolgende Quellenübersicht listet diverse jar-files und weitere Quelltexte auf, die Demonstrationen über funktionierende FileSharing-Systeme und Netzwerkstrukturen geben: Java RMI How to Use WebCanal Channels Beispielclient Da ViSe andere Anforderungen hat, sind diese Quellen nur als Anregungen zu verstehen. Sie sind so verständlicherweise nicht in ViSe übertragbar. Es wurde noch eine Software gefunden, die die Anforderungen darstellt, die ein Fileserver/-service haben sollte. Unter dem Link: ist dieses namens DIME von Microsoft beschrieben. Die dargestellten Quellauszüge sind dabei weniger hilfreich, aber für Anregungen der Darstellung genügte es für das erste. 11

12 4.2. Funktionalitäten Daran abgeleitet folgt jetzt eine Übersicht über die Funktionalitäten/Anforderungen eines Fileservers. Einem Client sollte erlaubt sein, folgende Möglichkeiten nutzen zu können: - Dateien erzeugen, löschen, öffnen und schließen - aus Dateien lesen und in Dateien schreiben - die aktuelle Position innerhalb einer Datei ändern - Informationen über eine Datei erfragen Hierbei ist aber noch nicht die Frage der Rechteverwaltung geklärt, die gerade in ViSe eine Hauptrolle spielt. Deshalb entstand nachfolgende Tabelle, die dazu einen ersten Überblick bietet: Es könnten dabei auf dem Fileserver zwei verschiedene Bereiche (Verzeichnisse) existieren. Zum einen ein Arbeitsbereich, auf den in kürzeren Abständen zugegriffen wird und dessen Dateien sich in ständiger Veränderung befinden und zum anderen ein Archivierungsbereich, in dem abgearbeitete Themen abgelegt werden können. Auf beide Bereiche gelten unterschiedliche Rechte: 12

13 Funktion Guest User SuperUser Administrator Datei erzeugen Ja, in Ja, in AB Ja, in AB und Ja, in AB und Arbeitsbereich Archiv Archiv (AB) Datei löschen Nein Nein, außer eigene Ja, in AB Ja, in AB und Archiv unbearbeitete Dateien Datei öffnen Muss sich Nur AB AB und Archiv AB und Archiv Erlaubnis von Admin einholen nur AB Datei schließen Nein Nur AB AB und Archiv AB und Archiv Aus Dateien lesen und in Dateien schreiben Informationen über eine Datei erfragen Nein Nur AB Nur AB, bei Erlaubnis von Admin auch Archiv AB und Archiv Nein AB und Archiv AB und Archiv AB und Archiv Wie zu sehen ist, hat ein Administrator hier die Hauptaufgabe zu übernehmen, den Arbeitsbereich zu überwachen und gegebenenfalls zu säubern. 13

14 Für das Verständnis des Gesamtkonzepts der Rechteverwaltung verweise ich hier auf die Dokumentation von Erich Bruns Der Fileserver für ViSe Es gab zwei Möglichkeiten, den FileServer zu realisieren. Die erste wäre, die File- Sharing-Funktionalitäten in den bestehenden Server zu integrieren oder die zeite, einen speziellen Server, der ein PseudoClient sein soll, zu implementieren. Es wurde sich für die zweite Variante entschieden, da der Hauptserver so weit wie möglich von zusätzlichen Aufgaben befreit sein sollte. Über diesen findet die Kommunikation statt, d.h. auch wenn der Fileserver in Betrieb ist, kann nicht darauf zugegriffen werden, wenn der Hauptserver nicht läuft. Auch wenn der Fileserver nur einen PseudoClient darstellt, so müssen doch trotzdem alle Funktionalitäten implementiert werden, die einen Server ausmachen. So müsste die Kommunikation zwischen den beiden vorhandenen Servern auch über einen Socket, beziehungsweise ServerSocket stattfinden. Die zu transportierenden Dateien legen also nicht nur den Weg Server Kanal Client zurück, sondern Server Kanal - Server Client, was einen großen Kommunikationsaufwand darstellt. Als ein weiteres Problem erwies sich die Versendung des Inhalts der Dateien. Da diese, wie in ViSe praktiziert, mithilfe von Messages transportiert werden, müssen diese erst konvertiert werden. Da dieses Problem nicht unmittelbar im Zusammenhang mit ViSe stand, wurde das Programm außerhalb von ViSe implementiert. 14

15 5. Das Programm Das Programm stellt ein Gerüst für den Filetransfer dar. Die Dateien können über Messages zu einem Server geschickt werden, und von dort wieder abgerufen werden. Um wie in diesem Fall beliebige n-zu-m-kommunikationswege realisieren zu können, wurde ein sogenannter virtueller Kanal implementiert. Ein weiterer Vorteil liegt darin, dass sobald der Server gestartet wurde, die Reihenfolge des Startens der Clients beliebig ist. Den Unterschied zwischen Kanälen und virtuellen Kanälen zeigt folgende Abbildung: Quelle: Kredel, Yoshida: Thread- und Netzwerkprogrammierung mit Java, dpunkt.verlag, 2. Auflage, S

16 5.1. Der Quellcode Das Programm besteht aus folgenden Klassen: ClientFileService FileServer ChannelWorker FileService Message ServerTest Der Client Die Klasse ClientFileService stellt den Clientteil dar. public ClientFileService(String host, int port) Der Konstruktor definiert den gewünschten Server. Die Klasse besitzt außerdem folgende zwei Methoden: void puttoserver(string sourcepath, String targetpath, String sourcefilename, String targetfilename) void getfromserver(string sourcepath, String targetpath, String sourcefilename, String targetfilename) Innerhalb dieser Methoden wird die Datei in ein Message-Objekt gepackt. Folgender Ausschnitt ist aus der Methode puttoserver: Message message = new Message(); message.setcommand(fileservice.write); message.setdirectory(targetpath); message.setfilename(targetfilename); File file = new File(source); 16

17 FileInputStream in = new FileInputStream(file); Long len = new Long(file.length()); byte[] data = new byte[len.intvalue()]; in.read(data); message.setdata(data); oos.writeobject(message); Um den Dateiinhalt versenden zu können, muss die primitive Variable (file) mithilfe einer Wrapperklasse (hier Long) in eine objektorientierte Hülle gekapselt werden. Dann kann mit bereitstehenden Methoden auf diese Variable zugegriffen werden. So kann dann die Datei in ein Byte-Array gelesen und somit als Objekt zur Message hinzugefügt werden. Weiterhin wird festgelegt, wie die Datei- und Pfadangaben zu erfolgen haben. Pfadangaben sind so zum Beispiel nur dann gültig, wenn sie durch / gekennzeichnet sind. Das Pendant dazu ist die getfromserver-methode. Folgende Tabelle zeigt die Übersicht der Klasse, wobei Variablen durch ein - und die Konstruktoren und Methoden durch ein + gekennzeichnet sind. ClientFileService - socket: Socket - oos: ObjectOutputStream - host: String - port: int + ClientFileService (host: String, port: int) + puttoserver(sourcepath: String, targetpath: String, sourcefilename: String, targetfilename: String) + getfromserver(sourcepath: String, targetpath: String, sourcefilename: String, targetfilename: String) 17

18 Der Server Die Klasse FileServer läuft als Thread neben dem ServerTest-Programm. Es wird ein ServerSocket aufgebaut, der auf Verbindungswünsche von Clients wartet. Trifft einer in der run()-methode ein, wird ein neues ChannelWorker- Objekt erzeugt, das dann für den Client zuständig ist. public void run() { Socket soc = null; try { while (true) { soc = server.accept(); ChannelWorker worker = new ChannelWorker(this, soc); socketpool.put(soc,boolean.true); } } } Aus der Klassenübersicht geht hervor, dass als Quellverzeichnis d:\\fileserver\\data übergeben wird. Das setzt die Existenz eines solchen Verzeichnisses auf dem Server natürlich voraus. Dass das Verzeichnis hier statisch festgelegt wird, dient der Kontrolle. Es können somit nicht wahllos Verzeichnisse auf dem Server angelegt werden. Thread FileServer + DEFAULT PORT:int = ROOT DIRECTORY: String = "d:\\fileserver\\data" - port: int - mgr: FileServer = null - server: ServerSocket - socketpool: Hashtable + FileServer (port: int) 18

19 + main (args: String[]: void + run(): void + terminateconnection (socket: Socket) rootdirectory: String Der ChannelWorker Der ChannelWorker wird bei einer Verbindungsanfrage durch einen Client erzeugt und ist dann ausschließlich für diesen zuständig. Im Konstruktor der Klasse werden die Objektströme in und out aufgesetzt. Wenn eintreffende Messages der geforderten Form entsprechen, wird der FileService als separater Thread gestartet. Außerdem erfolgt durch die Methode sendtoclient() die Übertragung des übergebenen Objekts (der Datei) als Message in die jeweilige Richtung. try { } in = new ObjectInputStream(this.socket.getInputStream()); Object obj = in.readobject(); if (obj!= null) { message = null; if (obj instanceof Message) message = (Message) obj; if (message!= null) { service = new FileService(this,message); service.start(); } } 19

20 ChannelWorker - fileserver: FileServer - socket: Socket - service: FileService - in: ObjectInputStream - out: ObjectOutputStream - message: Message + ChannelWorker (fileserver: FileServer, socket: Socket) + terminateservice(): void + sendtoclient(): void rootdirectory: String Der FileService Der FileService stellt das Gegenstück zum ClientFileService dar. In den Methoden dieser Klasse werden die Dateien entweder clientseitig eingelesen oder auf den Server geschrieben. Wie das geschieht wird nachfolgend am Beispiel der Methode writefile gezeigt: public void writefile(string path, String filename, byte[] data) throws IOException { //File wird auf Server geschrieben path = path.trim(); filename = filename.trim(); if (path.length() > 0 &&!path.endswith("/")) path += "/"; if (filename == null filename.length() == 0) return; String pathname = worker.getrootdirectory() + "/" + path + filename; File file = new File(pathName); file.createnewfile(); FileOutputStream out = new FileOutputStream(file); out.write(message.getdata()); out.close(); 20

21 FileService + READ: int = 0 +WRITE: int = 1 - message: Message = null - worker: ChannelWorker = null + FileService (worker: ChannelWorker, message: Message) + run(): void + writefile (path: String, filename: String, data: byte[]) + readfile (path: String, filename: String) Thread Message Die Klasse Message ist ViSe entnommen. Außer einer anderen Bezeichnung und veränderten Variablentypen, die aber die Funktionalität nicht ändern, ist die Klasse die selbe und erfüllt somit auch die selben Aufgaben. Message + Message() + Message(directory: String, filename: String,data: byte[], command: int) data: byte[] directory: String filename: String command: String Serializable 21

22 Der Test Die Klasse ServerTest stellt eine Testapplikation dar. Eine Datei wird vom Client zum Server geschickt, und von dort wieder zurück gesendet. Das ganze wird in einer Schleife ausgeführt, sodass sich nach dem Durchlauf des Programms 10 Kopien der Datei im eigenen Verzeichnis befinden und 10 in dem Verzeichnis auf dem Server. + ServerTest() + testit(): void + main (args: String[]: void ServerTest 5.2. Die Ausführung Um den Fileserver mithilfe von ServerTest testen zu können, sollte sich der Anwender zuerst folgende Verzeichnisse anlegen: c:/vise c:/fileserver/receive d:/fileserver/data Das Verzeichnis c:/vise ist das clientseitige Verzeichnis, in dem eine Datei namens home.pdf liegen muß. Es sind natürlich auch andere Dateien möglich. Dafür muss aber ServerTest modifiziert werden. Des weiteren muß der entsprechende host übergeben werden, wenn der Test über zwei Rechner erfolgen soll. Da die meiste Zeit mit localhost gearbeitet wurde, ist so auch die Voreinstellung. Bei verteilten Tests funktionierte der Fileserver auch. Nun kann der Server gestartet werden. Es sollte folgende Ausgabe erfolgen, die den Start bestätigt: 22

23 Wenn dann der ServerTest aufgerufen wird, sollten folgende Ausgaben in dem Konsolenfenster erscheinen. Konsole des Servers: 23

24 Konsole des Tests: Ab und zu (1 von 20) ist der Transfer nach einigen Durchläufen abgebrochen, was damit begründet werden kann, dass die Rechenleistung, bzw. die Kapazität des Rechners nicht ausreichend war. Bei erfolgreichem Durchlauf sollten sich natürlich die jeweiligen Kopien in den entsprechenden Verzeichnissen befinden. 24

25 6. Ausblick Während der Arbeit stellte sich heraus, dass allein das Problem eines Fileservers so komplex ist, dass es würdig wäre ein komplettes Forschungsprojekt einer Gruppe und auch mehr als ein Semester auszufüllen, da alle Bereiche, die es in ViSe allgemein gibt, auch in diesem Kontext bedacht werden müssen. So ist es nicht nur die Rechteverwaltung, sondern auch eigene nicht unerhebliche Whiteboardapplikationen, GUIs und weitere serverspezifische Funktionalitäten müssen sehr genau durchdacht und implementiert werden. Weitere Punkte sind die Sicherheit und die Stabilität. Sicherheit innerhalb des Netzwerks stellt eine eigene große Aufgabe dar. Stabilität ist eine Grundvoraussetzung. In diesem Fall wird dafür vor Allem Zeit für Statistiken benötigt, die aufzeigen unter welchen Umständen der Fileserver seine Arbeit verrichtet und unter welchen er abbricht. Aus oben genannten Gründen hat sich im Laufe des Semesters meine programmiertechnische Arbeit deshalb immer weiter auf den Kern des Problems beschränkt, welcher dann auch gelöst werden konnte. 25

26 7. Quellenverzeichnis - Kredel, Yoshida: Thread- und Netzwerkprogrammierung mit Java, dpunkt.verlag, 2. Auflage - Krüger: GoTo Java2 Handbuch der Java-Programmierung, Addison- Wesley, 2. Auflage Distributed Java Programming mit RMI und CORBA FileService mit RMI 26

27 8. Anhang Die UML-Darstellungen der Klassen 1. ClientFileService 2. FileServer 27

28 3. ChannelWorker 4. FileService 28

29 5. Message 6. ServerTest 29