ANTS 1.2 shared one name space between all capsules. This prevents protocol developers from using the same names for otherwise completely unrelated protocols, and requires the restart of one node when capsule code had to be changed, but retained its name.
We now create one class loader per protocol. The capsules of that protocol live in that name space. Note that only the capsules themselves are instantiated in this new name space. Applications, for instance, are not. This means that two unrelated applications running on one node may not use the same class name for their (unrelated) capsules. (This is one of the next things to fix.)
Secondly, ANTS 1.2 used one thread per channel to process packets, independent of which protocol they belonged to. This does not allow the assignment of CPU time on a per-protocol basis. In addition, since ANTS 1.2 lacked timers to kill off longer-running capsule evaluation, a malicious capsule could stop the system, not just the protocol to which it belonged. While the latter problem could have been solved by adding timers and a scavenger thread, as alluded to in the documentation, we believe that firing up one thread per protocol is the right approach. We believe that the startup costs will be amortized, just like the costs for the code-on-demand loading protocol are expected to be amortized.
Unknown capsule types are first picked up by the DLProtocol, and a DLRequestCapsule is sent to where the capsule came from. At the same time, a new Method object is created and an entry in the code cache associated with it. This method creates a new flow handle. The ``suspended'' capsule is enqueued on the flow handle. Once the first DLResponse capsule is received, a new CodeGroup is created with its own flow handle. The flow handles of all methods belonging to that code group are merged with that flow handle, i.e., their packet queues are concatenated. If the first code group is complete, a new InChannel is created. This InChannel is provided with the code group whose completion caused its creation. During initialization, it will create a new class loader and use that class loader to load the classes into the JVM. The new InChannel will obtain the code group's flow handle and start evaluating the capsules queued on it. It can be seen that flow handles allowed us to get rid of the additional Waiter objects in ANTS 1.2.
It should be noted that there is a potential for a denial-of-service attack as well as for an accounting problem here: the memory used by the DLProtocol to store the byte arrays containing the bytecode cannot by charged to any protocol before the protocol is known. We consider this unavoidable; out of band methods must be used to deal with an attack where nodes abuse the DLProtocol to deplete a router's memory resources. Once the protocol is known, the memory allocated for it by the DLProtocol must be ``transferred'' to the newly created InChannel, since it must be charged to its budget. (This is not done yet.)
As mentioned above, flow handles are associated with free queues. At dispatch time, packets are discarded if the free queue is empty. Therefore, the InChannel must ensure that the flow handle it serves has at least one buffer in its free queue. Normally, the buffer used by a capsule can be reused immediately after its evaluation. In some circumstances, for instance, when the capsule was delivered to an application, this is not possible and a new buffer must be allocated to replenish the free queue.