Table of Contents

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 for detail).  Click processes listed below to see their state transition diagrams.  Routers: IGMP, RSVP, QOSPF Hosts: IGMP, RSVP, UAPP, MAPP, RAPP

 

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" state.  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();
if ( in_strm > IP_STREAM )
app_inf_intr = TRUE;
else
data_decap_intr = TRUE;
 
So if the incoming stream is the IP_STREAM, the execuation goes to data_decap state.

Another way to decide the transition direction is based on the intrpt_code.
 

#define ARR op_intrpt_type() == OPC_INTRPT_STRM
#define SELF_INT (op_intrpt_type () == OPC_INTRPT_SELF && op_intrpt_code() == 0)
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.

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 processes code.
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.

Table of Contents