Re: JANOS+ANTS: nodes crash when old code is replaced with new?

[Robert Watson <rwatson@tislabs.com>]

On Sat, 5 Feb 2000, Patrick Tullmann wrote:

> Robert Watson wrote:
> > I've been experimenting with a custom form of the ping application, with
> > the intent of playing with some security stuff.  However, I've observed
> > the following behavior: when the code for mypingcapsule is first
> > distributed across my test network, it works fine.  If I then modify the
> > code, and perform a second ping, the first node it reaches that still
> > cached the old code dies with an out of memory error (attached below).
> 
> There is a bug in the last version of janos in the UdpBuffer code that 
> over-aggressively allocates memory for incoming packet buffers.  A
> simple hack would be to change UdpBuffer.getFree() to allocate a
> buffer on demand, and make addBuffers() a no-op.  (I forget exactly
> how much memory we were allocating, but it was something ridiculous
> like 32Mb per protocol... :)

Patching JANOS to allocate on demand seems to work great, so I'm making
some progress now :-).  BTW, don't know if you've thought at all about
masking the ANTS Node calls at all for visiting code, but the following
code in a capsule will cause the node to flake out:

                try {
                        n.register(null);
                        System.out.println("registered protocol null");
                } catch (Exception e) {
                        System.out.println("n.register() threw " + e);
                }

In our SANTS implementation, we used Java's strong typing to allow us to
limit access to privileged Node functionality.  We did this by having Node
implement a number of interfaces, depending on the code's role, and
handing out the interface cast of the Node instead of the Node itself.  We
limited recasting back to Node again (or to other types) by making the
ClassLoader for the visiting code not provide access to the base Node
class (i.e., preventing it from using the type).  We actually also stuck
another layer in, the Services class, which wrapped Node, but that is not
strictly necessary.  We had three interfaces--ServicesI for regular
visiting code, SystemServicesI for privileged code, and provided access to
submit code to the code cache, and was used for the DLBootstrap stuff, and
ApplicationServicesI, which was given to local applications to let them
submit their capsules to the Node.

This, along with retrictive use the Java's namespacing support via class
loading, significantly cleans up the set of exposed interfaces.  With a
NodeOS abstraction in there two, it might be desirable to do this at
several layers (which we also did, limiting EE access to the NodeOS and
system resources).  Unfortunately, our code relies on ava 1.2, but all of
this can be done in Java 1.1.

Robert Watson