Separation of ANTS run-time and Node OS services. Work-in-progress. Two services extracted: dispatching incoming packets, scheduling of outgoing packets.

Dispatch framework for incoming packets.

ANTS: - the channel entity would send and receive  capsules
      - Channel base class : encode, decode.
      - Channel subclasses : send and receive 
      - ChannelThread      : loop receiving, decoding, executing channel's packets

UTAH: - Channel class separated into:
	1. Channel   : sending (includes scheduling) and encoding
	2. InChannel : executing packets; has a thread so it loops (similar to
                       ChannelThread)
      - NodeOS : packet dispatching (and ANTS runtime - described below)

Flow dispatchers. Use a chain of dispatchers, a class that implements the Utah Dispatcher interface. Dispatcher has one method: to accept packets. Since these routines execute at non-accounted-for interrupt time, must be bounded: don't make copies of the buffer. Trusted dispatchers adhere to boundedness restrictions; untrusted (such as those used by untrusted active code extending the dispatch chain) are implemented as subclasses of trusted dispatchers and only implement a single untrusted accept-packet/drop- packet method (akin to traditional packet filters).

Flow handles. Unit of resource consumption. Special kind of dispatcher associated with two queues: packets to process & free buffers. In its dispatch routine, checks for a free buffer; if one is free, "exchanges" it for the packet. "Flow handles must be supplied with buffer space up front" (by those that create the flow handle, i guess). This provides a way to charge the creator.

Dependent buffers. Dispatchers cannot copy buffers (boundedness), so how can the same packet be passed to multiple flows? Utah has a way to do this such that each flow can have its own copy, yet by the time the copying is done, the owner is known and can be charged. Copying is postponed until a write is done. The first flow given the packet has the "master" copy. Subsequent flows have dependent buffers chained off the master. If the master copy is modified, it copies the data to the first dependent in the chain and calls that the master. If a dependent needs to modify the buffer, it copies the master into its own and removes itself from the dependent list.

I thought that ANTS protocols corresponded to a packet type. However, paper says that in ANTS a protocol could have multiple code groups and each code group could have multiple packet types. In Utah ANTS, protocols can spawn threads and associate flow handles with the new threads such that they can control their resources in a more fine-grained manner.

Overhead. Currently the implementation is in usermode so we have to use a special thread to receive the packet from the OS's interrupt handler and demultiplex to the correct flowhandle thread. With OS support, this extra context switch will go away.

	now:   OS -> special receiving thread -> flowhandle thread
	later: OS -> flowhandle thread

Separate name spaces and threads per protocol.

	ANTS: shared name space for all capsules
	UTAH: new class loader for each protocol (not applications, just capsules -
	      to be fixed)

	ANTS: one thread per channel + no timers (malicious capsule could
	      kill system)
	UTAH: one thread per protocol TO BEGIN WITH - the protocol may start
	      up more + other flowhandles

• Unknown packet types are dispatched to a thread that demand loads code. The node os can determine for itself how much time it wants to spend loading unknown protocols.
• acctg problem and potential for denial-of-service attack: the memory used by the DLProtocol (DL = demand load) to store the bytecode cannot be charged to any protocol before its known. "We consider this unavoidable; out of band methods must be used to deal with..."