Re: NodeOS questions

[Patrick Tullmann <tullmann@cs.utah.edu>]

Glad to hear folks are using the code for real stuff!  (We've only
seen bug reports in the build and test process so far on the
janos-discuss mailing list... :)

> 1) Flow management
> Our question involves the implementation of more complex protocols,
> such as reliable transport, in the EE.  In this case, a flow of packets
> for a given AA will contain some packets that will be processed by the
> AA and others that will only be processed by the EE.  The later includes
> packets such as SYN, ACKS, and retransmissions.

Like Steve and Larry, I think you want to make these more complex
protocols some sort of library service provided by the EE.  The NodeOS
flow model leans strongly in this direction (which is a very good
thing, IMNSHO).  As far as I know it would be superior to charge the
memory and CPU used in this processing directly to the AA that's
actually using the packets.  Is there a compelling reason to separate
resource accounting of these protocols from the AA that is using them?

For example, in ANTSR all of the "ANTSR" protocols (like code loading)
are provided to the AAs as libraries.  Thus the AA gets charged for
the time and space required to ship its code around.

> To hand of the packet to the AA, the EE will need to move the
> resources (memory and possibly the thread) to the target AA
> flow/mempool.  How is this accomplished using the NodeOS interface?

There is no way to hand off resources.  The way the NodeOS is designed 
you can strictly separate the EE-level resources from the AA-level
resources, if you really want.  There are some really hacky interfaces 
in the Janos stuff for "pushing" a packet into some other flow's
InChannel (i.e., the target flow can't tell if the packet actually
came off the wire or was put there by another flow).  Look for
InChannelHandle.  We use this in the ANTSR bootstrapping code to push
accumulated packets into a new flow just after the new flow starts.
Again, though, there is a strict separation of the resources here.


> 2) Is porting to the Janos Java bindings the right goal?

If you want your AAs to run in Java, I think this is the right goal.
We have a port in progress of the Java bindings to our
C-implementation, so your Java code should eventually run on the
"real" NodeOS (albeit with a Java<->C layer between it) without much
work on your part.  (The status is that we have a port of Kaffe that
uses the NodeOS thread abstractions for its native thread layer, and
we're just about to start on the "interesting" APIs in the
NodeOS--channels, flows, etc.)

Other NodeOS developers should be able to adapt our Java<->C NodeOS
bindings without too much effort.  (Assuming the NodeOS standard works 
as it should... ;)


> The current Janos interface *excludes* the protocol specification
> from the channel constructors and implicitly assumes "ip/udp".

Yeah, the current Janos interface predates the most recent NodeOS
channel specification.  We will gladly accept changes to bring the
Java level more in line with the spec.  We'll eventually get around to
this.  My initial guess is that the Java-level DemultiplexKey will end
up encapsulating all of the protocol and addressing information in
addition to the vanilla demux key.  Though I'm open including the
protocol and addressing stuff directly in the Channel constructors,
too.


> In the ASP EE we would like the protocol specification to be exposed
> by the Janos interface so that AAs can can specify the interception
> of both UDP and raw IP packets.

This is definetly something we also want to do.

> When specifying packet intercept from the Janos Java interface, it
> is unclear to us why the udp port is not part of a demux key.  

Here the Janos API reveals that we've only run ANTSR on it.  That's
all that it needed.... :)

You're definitely right that these APIs need to be updated to the most
recent NodeOS spec.  We might not get around to it for another month
or two, though.  If you guys want to make the changes, we'd be happy
to incorporate them back, otherwise, we will come get your input
before we start work on them.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu
	      Success means never having to wear a suit.