Modeling Process Logic
|Process Model defines the function of each protocol layer
in Node Model. The graph on the right shows the
action button panel of process model.
We have created or improved several processes for the model. Among them,
IGMP, RSVP, IP, ARP, MAC and QUEUE have different implementations on Routers
and Hosts, while Application processes (UAPP, MAPP and QAPP) only exist
on Hosts and QOSIP only exists on Routers. Each process is described by
a state-transition diagram. You can provide C code for each state and define
constants and variables in the header file. FAQ
shows how to configure the environment variables to use the online support.
There are several methods to schedule when and how your process to be
executed. You can use op_intrpt_schedule_self() to schedule the
time that current process will be reexecuted. op_intrpt_schedule_remote()
schedules another process in the same node to be executed after current
process finishes. While op_intrpt_force_remote() force another process
in the same node to be executed immediately, and current process will continue
running when the remote process returns. You need to provide the intrpt_code
as a parameter in these funtions, the scheduled process will decide the
state transition depending on the code (see below
Click processes listed below to see their state transition diagrams.
There are two kinds of states,
is an unforced state. During the simulation, an unforced state will execute
its enter executives, then pause, allowing the simulation to turn its attention
to other entities and events in the model. Normally, it is used for "idle"
is a forced state, that is, it will execute its enter executives and exit
executives, then pass control to the next state via a transition. You can
setup the name and type of a stetes by right-clicking the state. Left-click
the upper half of a state, you can review or write C code of the enter
executives. The lower half defines the C code of the exit executives.
Click to create
a normal state and click
to create an initial state. An initial state is used to set the initial
values of variables in the process, and this state is usually executed
only once when the process is first "awakened". Awakening may occur at
the beginning of the simulation if the "begsim interrupt" is enabled in
the process attributes dialog defined in the node model. Otherwise, awakening
may occur when the first interrupt arrives at the process.
Click to create
a transition. The solid line in process model indicates a transition
without condition, which means the source process will transfer the
control to the next process after its job get done. The dash line indecates
a conditional transition, which means the transition only happens
when a certain condition is fulfilled. You can right-click the transition
line to edit its attributes.
The dialog above shows the transition (spillter -> data_decap)
attributes in the IGMP process on the Host. If the condition "data_decap_intr"
is true, the spillter state will transfer to data_decap state.
We wrote the C code in spillter state:
in_strm = op_intrpt_strm();
So if the incoming stream is the IP_STREAM, the execuation goes
to data_decap state.
if ( in_strm > IP_STREAM )
Another way to decide the transition direction
is based on the intrpt_code.
#define ARR op_intrpt_type() == OPC_INTRPT_STRM
Also in the IGMP on HOST process. See the idel state, there are
two possible transitions. When the process get an interuption, by using
op_intrpt_type(), it first checks weather the interuption comes
from a incoming stream or a self schedule. Next it checks the intrpt_code
getting from op_intrpt_code(). If ARR condition becomes true, the
execution will take ARR transition. Otherwise, SELF_INT transition
will be taken.
#define SELF_INT (op_intrpt_type () == OPC_INTRPT_SELF &&
op_intrpt_code() == 0)
In the action button panel, there are several buttons for defining
the constants, variables and code for the process:
is to define state variables.
The variables defined here are local variables. Each node has its own copy
of the state variables, and they will retain their value from one process
invocation to the next.
is to define header block.
The constants and variables defined here can be considered as globe data.
They are shared by the same processes at every nodes.
defines temporary variables,
which means data will be initiated when the process begin and get lost
when the process is finished.
is to define function block.
You can provide the functions for the process here.
Click , you can see the
full C code list, including header, variables definitions, functions and
Everytime you make any change to the code, you should first save it
by clicking and click
to compile the process code.
Opnet 2.5 or above version provides its own text editor to edit the
code. If you still prefer your own tools, you can make a new script file
at OPNET system bin directory (here is an example for vi),
and change the editor_prog item in your environment database file
to specify the directory and program name of your script.