Last commit for 2-Do: 26cf4363e26241ef68ec6d2fe1fe1c6b3258a448

some testing, some code cleanup

gskc [2002-06-28 20:21:19]
some testing, some code cleanup
28 June 2002
  - debug flag determines what stuff is printed to console .. maybe
    play around with err / out streams
  - incorporate sanity checking of rmi Registration both at the hosted
    rmiRegistry, and at the RTU: cannot rebind to an existing name ..
    ensure have similar mechanisms and policies in both RMI
    registration, and WVM registration/lookup system
  - enable worklets to attach themselves to hooks in the WVM, so that
    they can specify callback methods that the WVM can invoke upon
    certain 'interesting' events taking place in the WVM. Expected
    applications: network logging setup by incoming worklet, alerted
    when worklets / messages, etc arrive

11 April 2002
  - integrate proof-carrying code into worklets along with standard
    authentication mechanisms based on public keys and certificates

27 March 2002
  - separate classLoader for each incoming Worklet, to prevent name
    clashes between namespaces of different worklets

27 February 2002
  - tiny blackboard within WVM to assist with coordination between
    locally executing Worklets.

23 February 2002
  - RMI Registry 'delegation' takes too long?

25 January 2002
  - specify port number when creating WVMs                            :)

03 December 2001
  - WVMs save and reuse connections to peer WVMs

29 November 2001
  - setSoTimeout on WVM, WVM_Transporter, ClassFileServer threads,
    and Thread.join() at shutdownHook
  - WVM_RMI_Transporter$RTU does *not* rebind to the rmiregistry,
    instead, it binds, and unbinds @ the end .. also, the local
    rmiregistry will poll bound services to check they're still
  - WVM maintains a message queue for the hostSystem, and provides
    a mechanism for peer WVMs and their hostSystems to achieve
    message-passing ... this will be used for control-passing
  - _activeWorklets is static in WVM .. change this
  - determine practicality+usage of WVM.getMessage(msgKey);
  - modify WVM's requestHandler so that it can choose from a variety
    of requestHandlers provided by the hostSystem
  - use the 'locking-trick' from MP-Oracle for synchronising threads
    and provide that as a primitive in the WVM

14 November 2001
  - SystemDispatch should be able to carry over system property
    values set on the command line: -DDEBUG_LEVEL=50

03 October 2001
  - increase capability of SystemDispatch:
    + add ability to pass cmdLine params to app being dispatched      ;)
    + add ability to transfer files from local FS to target site      ;)

24 July 2001
  - incorporate a 'ping' mechamism in WVMs                            ;)

20 July 2001
  - make WJ implement runnable instead of Wkl ... this will be needed
    when we have the WJack dictate that the WKL drop off the WJ and
    leave it to execute [in its own thread] later on
  - add: addNextJunction in

16 July 2001
  - WVMs require an ACK from peer WVMs confirming receipt of worklets ;)

11 July 2001
  - add conditional progress of worklets, ie decide to go to Hop_B or
    Hop_C from Hop_A -- this can be used to have programmable routes
    for worklets where they can re-visit certain nodes in a loopy
  - add a central "WorkletEngine" entity to the worklets that will
    persist throughout the lifetime of the worklet, and can be used
    to manage and oversee the WorkletJunctions
  - Use Marshalling to keep unwanted WorkletJunctions unresolved at
    intermediate hosts

21 June 2001
  - set the 'origin' site's WebServer URL in each created WJ
  - get rid of last-host, last-name, last-port info .. or put it to
    better use, e.g. use this as well as last-WebServer as part of
    the 'route' of the Worklet
  - in Worklet, merge 'deployWorklet' and 'moveToNextJunction' ...
    this might force us to have to pass the WVM as a parameter
    to the Worklet Constructor ... this will help in setting
    the 'origin' site information in all 'added' WorkletJunctions
  - get rid of 'classHashSet' from Worklet, and also the other
    hashSet used to keep track of the classes loaded dynamically

20 June 2001
  - Incrementally 'save' the route of the Worklet as it passes
    through each target host .. this can help in identifying
    all surviving nodes if parts of the system were to go down

19 June 2001
  - Every workletJunction carries local info:
    + original site codebase
    + received-from site codebase
    + it's received-from site codebase

19 June 2001
  - WVM_RMI_Transporter: send modified codebase 4 forwarded worklets  ;)
  - see if RMI runtime can use the WVM_ClassLoader instead of the
    default RMI_ClassLoader
  - WVM_ClassLoader: test bytecode extraction for classes loaded
    remotely                                                          ;)
  - Major modification of WVM_ClassLoader:
    + instead of subclassing URL_ClassLoader, we can subclass
      ClassLoader directly .. so, now we'll have to implement the
      receiver side of the http pull too, this time on the
      WVM_ClassLoader though!                                         ;)

05 June 2001
  - public static final int java.rmi.server.ObjID.Registry_ID = 0;
    this is the ID set for the single instance of the RMI Registry
  - to change this, need to:
    + negatively increasing ObjID numbers for all registry instances
    + look at the RMI runtime system to see if can reasonably well
      implement efficient lookup of rmi registries @ runtime

04 May 2001
  - customised protocol handlers
  - customised protocol: eg. WBTP, Worklet Bytecode transfer protocol

05 April 2001
  - lookup digital code signing

04 April 2001
  - Signed WorkletJunctions, c.f. PGP
  - Domains / levels for NRL worklets, ordered by
    security or clearance

28 March 2001
  - RMI will load the classes from the source site's http server
    automatically ... so sending the default bytecode retrieval
    worklet will not do any good in this case ... might need a way
    to retrieve the classes locally in any case .. lets see how...

27 March 2001
  - WVM_ClassLoader can detect every time a class is loaded
    from the source site via the URLClassLoader and custom
    http server. While Worklet is being loaded from the socket
    connection, the executing thread is the transporter .. it will
    have a hashset for collecting the names of all classes loaded
    through WVM_ClassLoader .. when the object is done being loaded,
    the transporter will send a bytecode retrieval worklet to the
    source site to collect the afore-mentioned Classes' bytecodes.
  - Also, when the Worklet is done executing, the names of all the
    classes that were loaded from the same http server is retrieved
    from the hashset stored in the worklet itself. Before this worklet
    is sent out to its next junction, a bytecode retrieval worklet is
    sent to the source site again .. this time to retrieve those classes
    that were loaded during the execution of the workletjunction.

26 March 2001
  - Look at URLConnection, URLStreamHandler to customise ProtocolHandler
    Also, customise ContentHandler ...
  - Integrate light-weight WGC w/ WVMs so that target WVMs will be
    prepared w/ pre-cached class bytecode for any incoming Worklets
  - quick solution for sockets transporter: get list of classes from
    WVM_ClassLoader ... when complete Worklet has been read in, use this
    list to retrieve the classes from the source WVM

24 March 2001
  - use WGCache in WVMs ...
  - WVM ClassLoading supports transitive ClassLoading for
    ephemeral WVMs: bytecode is required immediately. As
    bytecode is needed during execution, the WVM is not
    guaranteed URLClassLoading from the origin and/or any
    intermediary WMVs
  - Transporter layer [sockets & rmi] is responsible for
    setting up BAG - MULTISET for storing information
    about the classes served up by webserver. As webserver
    receives each request, it will locate the corresponding
    BAG-MULTISET using the remote IP as primary key, and
    either RMI-name or Port as secondary key. With either
    transportation mechanism, the classes for URLLoading
    are served up by the same webserver on the sender
  - At the target site, the transporter layer has to
    send the RetrieveWJ

23 March 2001
  - WVM will send out a worklet with all cached files that
    happen to be requested via URLClassLoaders ... this can
    take place every N seconds. This worklet will go to all
    sites that requested bytecode within the last N seconds.
  - WVM keeps a hashtable of className:codebaseURL for classes.
    Entries will be added as class names / codebases are received
    by the sockets layer. Entries are updated if classes are
    later on cached locally.

22 March 2001
  - Make WVM.out be a wrapper round a real PrintStream object

21 March 2001
  - ClassFileServer will collect all classFiles served
  - Target site will send a standard worklet to sender to
    retrieve all accessed class files from sender
  - this worklet will know about *only* those classes that
    the target site had to load remotely ... and hence, the
    worklet will retrieve the bytecodes for only these classes

18 March 2001
  - Same JVM cannot shutdown an RMIRegistry and start another one ...
  - have a -v ... --visual option to WVM .. to indicate VISUAL

15 March 2001
    add to ClassLoader: if className.startWith("psl.worklets"), throw
    new ClassNotFoundException: this will prevent classloaders from
    loading any "new" psl.worklets class

12 March 2001
  - use RMISocketFactory for +1 Registries in the same JVM

10 March 2001
  - add WVM.out: a PrintStream oject, same as System.out by default   ;)

07 March 2001
  - kill -9 does not let the shutdown thread execute, so
    the next Registry will not be nominated ... in such a
  - need security mechanism so that only those worklets that
    can present a known set of credentials are allowed to

05 March 2001
  - Worklets making persistent changes to the target site.

04 March 2001
  - RTU should try to [re]-establish RMI registration
    + possibly [re]-create RMI Registry
    + possibly [re]-register with RMI Registry

04 March 2001
  - modify ClassFileServer to "spy" on outgoing Class files,          ;)
    and also cache them
  - subclass URLClassLoader to "cache" URL-Loaded Class files,
    and dump to local file system

03 March 2001
  - add java.rmi.registry.LocateRegistry                              ;)
    + first app creates registry                                      ;)
      - others getRegistry() and work from there                      ;)
      - when first app unregisters, it "notifies" other apps          ;)
      - one of the other apps then creates registry                   ;)
    + if registry exists, join                                        ;)
      - if registry sends "notification", re-join                     ;)
        + if unsuccessful after 3 attempts, create registry