Some of the concepts used in the direct network module provided by Proteus for hop-by-hop network simulation were used in the design of the indirect network module.
For example, as stated in Section 2.1, in order to simulate network contention and message latency, Proteus time-stamps the input and output ports of a processor's switch structure (i.e., an array). Thus in-coming and out-going messages will be received or routed respectively, with the appropriate time delay.
Although we use the same Proteus events to move a packet through the network, our indirect module operates differently.
Processors are no longer involved in routing packets as in the direct network module. The processors are only responsible for generating the initial route request for a send and handling the receipt of a packet from the switch on a receive. All subsequent routing is done by the switches in the interconnection network once the packet leaves the source processor.
There were some limitations to Proteus' communications module that we attempted to address in our implementation. First, we put a thin message passing interface, similar to IBM's MPL [5] on top of the low-level send/receive packet handling routines. For simplicity, we only implemented blocking send and receive calls, as does Proteus.
One other limitation of the Proteus communication module is that it supports only set sized packets per send call from the user application. Where as, in our module we support varying sized messages per send/receive call.
Also, we implemented typed messages so as to give an application more flexibility when having to communicate different types of data.