Small logo of ETH main building ETH Zurich : Computer Science : Pervasive Computing : Distributed Systems : Education : DS WS 2006/2007

Verteilte Systeme

Hinweise zur Linux-Installation im Studentenpool

  • IP-PORTS: Generell ist auf Rechnern des Departements nur SSH nach aussen freigeschalten. Als Ausnahme sind die Ports oberhalb von 50000 für andere Rechner im gleichen Gebäude zugänglich (also IFW -> IFW, CAB -> CAB). Auf dem gleichen Rechner gibt es keinerlei Beschränkungen.

    Sowohl die RMI- als auch die CORBA-Übung können deshalb auf einem einzigen Rechner gemacht und vorgeführt werden.

    Hinweise zur Benutzung von RMI und CORBA auf einem selbstdefinierten Port:

    • RMI: Wenn die rmiregistry auf einem anderen Port betrieben wird, muss auch die URL zum Objekt im Client und Server geändert werden, Um z.B. auf das Objekt MyObject auf dem Host optimus, bei dem die rmiregistry auf Port 54321 läuft, zuzugreifen:
       "rmi://optimus:54321/MyObject".
    • CORBA: Da der Client über die Referenz-Datei Zugriff auf den ORB erhält, muss bei CORBA nur der Server angepasst werden. Es gibt hierfür 2 Möglichkeiten:
      1. Beim Erzeugen des ORB kann der Port mit Hilfe von Properties gesetzt werden.
        Properties properties = System.getProperties();
        properties.put( "org.omg.CORBA.ORBInitialPort", "54321" );
        ...
        ORB orb = ORB.init(args, properties);
        
      2. Der gleiche Effekt lässt sich auch beim Start des Servers auf der Kommandozeile erzielen:
         java Server -ORBInitialPort 54321

Hinweise zum RMI-Teil der Übung 2

  • Ein minimales RMI-Beispiel ähnlich dem in der Übung besprochenen findet sich hier: rmi-example.zip.
  • Seit der Java Version 1.5 ist es nicht mehr nötig, Stubs mittels rmic zu erzeugen, da diese zur Laufzeit per Reflection aus den Interfaces generiert werden. Aus diesem Grund ist es für die Übung auch nicht notwendig, dass Java-Code per RMI nachgeladen wird, da alle Operation auf dem Server stattfinden.
  • Falls Sie die nachfolgende Fehlermeldung erhalten, kann der Client resp. der Server die rmiregistry nicht erreichen, z.B. weil diese nicht gestartet wurde, weil die URL nicht korrekt angeben wurde oder eine Firewall den Zugriff verhindert. Versichern Sie sich in diesen Fällen, dass die rmiregistry läuft und probieren Sie das ganze auf nur einem Rechner aus.
    java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 
    	java.net.ConnectException: Connection refused
    	at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574)
    	at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
    	at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    	at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    	at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
    	at java.rmi.Naming.rebind(Naming.java:160)
        ...
    
  • Falls Sie die nachfolgende Fehlermeldung erhalten, so kann es sein, dass rmiregistry die entsprechende Klasse auf Grund eines falsch gesetzten CLASSPATHs nicht findet. Am einfachsten starten sie rmiregistry direkt im Verzeichnis mit den Class-Files und setzen dabei den CLASSPATH mit dem Kommando: rmiregistry -Jcp -J.
    Server exception: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
            java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
            java.lang.ClassNotFoundException: Banking.Bank
            ...
    
  • Falls normale Java-Objekte und deren Class-Files per RMI übertragen werden sollen ist jedoch folgendes zu beachten:

Dynamisches Nachladen von Java-Klassen

Beim dynamischen Nachladen von Java-Klassen zeigt sich die Mächtigkeit von RMI. Damit dies funktioniert müssen jedoch ein paar Dinge beachtet werden und zum Teil anders als in der RMI-Einführung gemacht werden. Speziell muss ein Security Manager gesetzt werden und diesem das dynamische Laden von Bytecode erlaubt werden.
  • Alle Klassen, von denen Objekte per RMI übertragen werden, müssen das Interface java.io.Serializable implementieren.
  • Beim Aufruf des Servers wird der angegeben, welche Klassen geladen und per RMI auch dem Client Übertragen werden. Hierzu braucht es eine gültige URL unter der die Klassen verfügbar sind, z.b. http://... für den Zugriff über das HTTP-Protokoll. Wenn gerade kein Webserver zur Verfügung steht, kann man aber auch eine file://... URL angeben. Diese sollte dann jedoch absolut sein, oder zumindest aus Sicht von Client und Server korrekt sein. Beachte die Anzahl der '/' in der URL. Bei einem absouten Pfad kommt zu den beiden '//' der URL noch ein '/' vom Pfad. Ganz wichtig: Die URL muss mit einem '/' enden, da die Klassen sonst nicht gefunden werden!
    Starten des Servers:
    java -Djava.rmi.server.codebase=file:///home/nethzaccount/RMI-aufgabe/ Server
  • In der Client-Anwendung muss zuerst ein RMISecurityManager instantiiert werden:
        if (System.getSecurityManager() == null) {
            System.setSecurityManager(new RMISecurityManager());
        }
    
  • Beim Client muss es eine Java Security Policy Datei geben, welche beim Start als Parameter angegeben wird. Es kann die Datei java.policy mit folgenden Inhalt verwendet werden:
    grant {
        permission java.security.AllPermission;
    };
    
  • Aufruf des Client mit Angabe der java.policy Datei:
    java -Djava.security.policy=java.policy Client

Hinweise zum MICO-Teil der Übung 2

Warnung beim Kompilieren der generierten Java POAs

Der vom aktuellen idl-to-java-Compiler von Sun erzeugte Source-Code für die POAs nutzt die neuen generischen Collection-Klassen nicht, was den Java-Compiler dazu veranlasst, die folgende Warnnung auszugeben:
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Daran lässt sich nichts ändern - der erzeugte Code ist trotzdem korrekt. :)

Installation

MICO ist auf den Linux-Rechner im IFW installiert, wie auch in der Übung besprochen. Für Leute, die MICO Zuhause auf ihrem Heimrechner/Laptop benutzen wollen hier unsere Resultat, geordnet nach Betriebssystem:

Linux

Unter einer aktuellen Linux-Distribution lässt sich MICO ohne Mühen mit der üblichen Sequenz nach /usr/local/ installieren:
configure
make
sudo make install

FreeBSD

Es gibt ein MICO-Paket in der FreeBSD Ports-Collection.

Mac OS X

Für Mac OS X haben wir die Fink-Pakete mico & mico-dev bereitgestellt, welche in Fink CVS Unstable verfügbar sind. Wie man Fink installiert bzw. zum Fink CVS Unstable Repository kommt ist hier erläutert: Ausserdem ist MICO dank eines Teilnehmers der Vorlesung jetzt auch im macports, der Mac Version der BSD Port Collection, vefügbar. Installation dort durch
port install mico

Windows

Unter Windows stehen mehrere Varianten zur Verfügung.
  • Cygwin: Am einfachsten geht es, wenn Cygwin installiert ist. MICO verhält sich unter Cygwin genauso wie unter Linux (problemlos). Am Ende der MICO-Kompilation wird ein Fehler gemeldet, der nicht weiter zu beachten ist. Zu diesem Zeitpunkt sind die MICO-Libraries schon komplett installiert:
    ldconfig
    make: ldconfig: Command not found
    make: [install] Error 127 (ignored)
    
  • Visual Studio 2003 .NET: MICO lässt sich auch mit Visual Studio .NET 2003 (aka Visual Studio 7.1, VC7.1) kompilieren. Hierzu bitte die Datei ReadMe.win32 beachten.

  • Visual Studio 2005 (Visual Studio 8, VC8) : Uns ist es (mit moderatem Aufwand) nicht gelungen MICO mit der aktuellen Visual Studio Version 2005 zu kompilieren. Wir empfehlen deshalb auf Cygwin umzusteigen oder das ältere Visual Studio zu installieren. Evtl. kann man auch die MICO dlls mit VC7.1 kompilieren und dann mit VC8 weiter arbeiten. Konkrete Hinweise, wie man MICO unter dem aktuellen Visual Studio nutzt, bitte an die mico-devel Mailing-List. :)
ETH ZurichDistributed Systems Group
Last updated August 23 2010 01:52:49 PM MET msr