Figure 1:
The new ANTS dispatch tree
Figure 1 shows the dispatch of packets in ANTS. Each box represents an implementation of the dispatch interface. The Node OS package provides a dispatcher for ANEP packets. This dispatcher accepts registrations for different ANEP types, to which incoming packets are dispatched. A special flow handle may be registered to which packets are dispatched whose types are unknown. A dedicated thread will pick up packets from this flow and provide the default behavior that ANEP demands.
In ANTS, packet types correspond to method IDs. The code cache maps these IDs to Methods. Therefore, the CodeCache class implements the dispatch interface to dispatch packets to the various methods. We changed the Method class to implement the dispatcher interface as well. There is initially one flow handle, i.e., one actual queue per protocol. However, one protocol may contain multiple code groups, each of which may contain multiple capsule types, corresponding to multiple methods. Currently, all methods dispatch incoming packets to their protocol's flow handle.
We include both built-in and (locally or remotely) loaded protocols in this scheme. Unknown packets are dispatched to a flow handle that is served by the internal protocol that initiates the loading of code on demand. In this way, the node can decide how much of its resources it wants to dedicate to route updates, built-in data capsules, and the loading of new protocols.
Our scheme will allow protocols to subdivide their resources: by creating an additional flow handle and spawning off a thread that serves it, a protocol can in the example shown in the figure dedicate some part of its resources to the processing of packets belonging to code group I, and another part to those belonging to code group II. If the packet types in code group I represented multicast subscriber capsules, and the packet types in code group II multicast data capsules, it can ensure that a flurry of subscriber messages does not interfere with an ongoing multicast, or that subscriber capsules will always processed with a higher priority than data capsules, depending on the specific requirements of the protocol. The next step will be to define the interfaces protocols can use to do this subdivision.