Frequently Asked Questions
Mobile Code Toolkit

compiled by Gatot Susilo
email: susilo@sce.carleton.ca
Last Updated: October 10, 1997

 

The following is a compilation of FAQ on the Mobile Code Toolkit. You may find answers from the common errors here. However, if your question is not answered here, you may email susilo@sce.carleton.ca and we will add it here. I use a mobile code to represent Netlet or Virtual Managed Component or any names of the mobile code derivation.

  1. Where can I download the package ?
    You may obtain a free copy of the software from http://www.sce.carleton.ca/netmanage/mctoolkit. We do not recommend that you redistribute the software to somebody else. However, we strongly urge everyone to download it directly from the site that we have been provided. Therefore, we can keep a track who got the software and what for what purpose is. Additionally, we can notify them when there is a new release coming out or bug fixed.
  2. What do we need to the run the toolkit ?
    The software is 100% written in JAVA; therefore all you need is to have JDK1.1.3 or above installed on your computer. Other development environment, such as IBM Visual Age for JAVA is optional.
  3. I have unzipped the package, and I tried to run the daemon. However, I got message "Can't find class mct.NetletDaemon".
    This is quite common problem at beginning of using new JAVA library. This is because you may not set your environment variable CLASSPATH properly. You have to add an entry of the path of the MCT classes into the environment variable CLASSPATH.
  4. How to add path into environment variable CLASSPATH ?
    In Windows 95 environment, you can add the entry in the file c:\AUTOEXEC.BAT. The entry should be:
    set CLASSPATH=%CLASSPATH%;c:\mctoolkit\v1.0\classes
    REMEMBER: you have to reboot the system to see the affect changed.

    In Windows NT environment, you go to Start | Setting | Control Panel | Systems. Go to tab Environment. You can add the entry there.

    In UNIX environment, you can add the entry in the file ~/.cshrc. The entry should be:
    setenv CLASSPATH $CLASSPATH:~/mctookit/v1.0/classes
    Then you should recompile it with command: source ~/.cshrc

    Once you add the entry, you can check the environment variable to see whether the entry has been added by launching command:
    set CLASSPATH (Win(5/NT)
    setenv CLASSPATH (UNIX)

    One reported that classes from JDK do not have to be included in the environment variable CLASSPATH. However, it is recommended that you always specify explicitly paths of classes that you are going to use in CLASSPATH.
  5. Yes, I have set up the CLASSPATH properly, but still I cannot run the daemon.
    To run the daemon, you need a configuration.file (see c:\mctoolkit\v1.0\conf). The daemon is implemented in a package called mct. Therefore, to run it from any current directory, make sure you put absolute class name (i.e.: java mct.NetletDaemon netletdaemon01.properties instead of java NetletDaemon netletdaemon01.properties).
  6. Yes, the daemon is instantiated. However, at some point, it says CLASS NOT FOUND.
    The author also found this problem. I can run the daemon and all the examples in my NT box. However, when I zipped and transfer them into UNIX box, I cannot run the daemon and it says CLASS NOT FOUND at some point. So I checked the associated classes. Hmm.. the classes are there, but why the class loader cannot load it.
    Ok.. perhaps there is a file corrupted somehere, so I rezipped the package and transfer it to the UNIX box again. Interestingly enough, I got CLASS NOT FOUND again but not on the same class as previous one. Again, again, I checked the associated class is actually there.
    So I decided to recompile the source code. Now the daemon is working fine.
  7. Can parameter contain any data objects other than String ?
    Yes, however, some limitation. Parameter can only hold data objects whose associated classes exist in the path as specified in the environment variable CLASSPATH (e.g., Integer, Byte, Float, InetAddress, etc.).
  8. If the security feature is installed, how can I bypass the security feature ?
    YES and NO.
    NO: Any mobile codes (Netlet, VMC, etc.) that are downloaded and intalled in the daemon, they can NOT bypass security feature.
    YES: However, any mobile codes that are installed during the daemon start up, they are not restricted with the security feature. This is simply because the code should be 100% trusted and can be used to extend new services of the daemon.
  9. Can I have two mobile code with the same class name run on one daemon ?
    NO, you cannot have two mobile code with the same class name run on one daemon. Before instantiating incoming a new mobile code, the instantiator will check whether the mobile code already exists in the daemon. If it does, the old one will be replaced with a new one.
    On the other hand, associated classes for the mobile code may have the same names. For instance, a mobile code A has classes A, B, and C; another mobile code P has classes P, B, C. Class B and C are common name for mobile code A and P and they may differ in their implementations. Both mobile code A and P can run simultaneously on one daemon. This is simply because each mobile code has its own name space.
  10. Shall the JAR filename be same as the mobile code name ?
    NO, you can give any name for JAR files and is not necessarily the same as the name of mobile code.
  11. When creating a jar file, do I have to manually list all .class files of an inheritance hierarchy ?
    JAR command line is like TAR command line on most UNIX box. If you create a mobile code and all associated classes as a package, you should get all classes required for your mobile code in one subdirectory. For instance, you have a mobile code with classes foo.java, and bar.java. You put those classes as a package namely moo. So the absolute class names are moo.foo and moo.bar. When those classes are compiled, they will be put under subdirectory moo. To jar those classes, you must include the subdirectory as well. The jar command should be:
    jar -cvf jarfile.jar moo\*.class
  12. On class mct.users.VirtualManagedComponent, I see a variable called stub that must be used to implement new interface. If I want to write a VMC which extends class mct.users.VirtualManagedComponent and implements few other interfaces such as mct.users.MCDExtension, or other else, how can I get a handle of a variable stub and use it to implement methods for MCDExtension ? For instance, in Netlet and Extlet template, they have a method getStub() to get the stub handle.
    Yeah, stub is a variable of MobileCodeStub that interfaces between mobile code and the daemon (mct.admin.MobileCodeManager). So to get the stub handle, you can overide method setStub() and call super.setStub(...) at the beginning of the method. Here is the example.
public class NewVMC extends VirtualManagedComponet implements MCDExtension {
   MobileCodeStub myStub=null;
   public void setStub (MobileCodeStub stub) {
     super.setStub(stub);
     myStub=stub; // Now I get the handle of stub in my class namely myStub
   }

   public StorageManager getStorageManager {
     if (myStub!=null) return myStub.getStorageManager();
     return null;
   }
   ............and so on........
}
  1. If the intent that all mobile code will be sent in .jar, then the mobile code class should implement Serializable. Why is it left to user in implementing a mobile code ?
    Serializable is one of choices for user to keep a persistent states of the mobile code. They can put the persistent states manually on the parameter facility of mobile code that implements mct.users.Paramaters. Jar is just a method to compress a mobile code and put it in one bundle.Indeed, it will make transferring mobile code more efficient that transferring class by class.
  2. What is Serializable ?
    Serializable is one of JAVA feature to allow instantiated JAVA code to be streamed out to socket or to file system. The result of serialization can be restored back with the same values of attribute.
  3. What is the persistent state ?
    Persistent state is that states of non-transient fields in the java classes are kept persistent. So when the class is restored back, the class has the same field values as before it is being serialized.

Copyright 1997, Gatot Susilo