Communication with Node Control Program

There are some issues to be discussed about how to communicate with Node Control Program. As we mentioned previously, the Simulation Engine is based on event-trigger. If no event exists, the Simulation Engine will advance its clock quickly.

Because node’s information is store in the Simulation Engine, if Node Control Program wants to know current node’s location, speed or direction of movement, it has to query Simulation Engine. When all Node Control Program has finished querying or sending information to Simulation Engine, Simulation Engine can advance its virtual clock. To take a simple example, Node Control Program will query node’s location at virtual time t1 in Figure5.2.2.2.1. If Simulation Engine can respond it immediately at virtual time t1 instead of advancing virtual clock, Node Control Program will get the information of location at time t1, which is what it really wants.

At virtual time t1, if Simulation Engine thinks all nodes have no longer communicated with it and advance its virtual clock to t2, but in fact one of Node

Control Program want to query its node’s location at t1. While Simulation Engine receives this query at virtual time t2, Simulation Engine will respond node’s location at t2 instead of location at t1. This results in inaccuracy and incorrect result. The question now arises is how Simulation Engine knows all of Node Control Programs has finished communicating with it.

Figure 5.2.2.2.1 Communication between Engine and Node Control Program

To answer this question, let us discuss the process scheduling first. Since we can understand this concept more fully in [21] we shall outline here only briefly.

In Linux, a user-level process also has two priorities: static priority and dynamic priority [22]. The static priority is assigned by the users for real-time processes and never changed by the process scheduler in the kernel. The dynamic priority is used for normal processes and is essentially the sum of the base time quantum (which is therefore also called the base priority of the process) and of the number of ticks of CPU time left to the process before its quantum expires in the current epoch. The static priority of a real-time process is always higher than the dynamic priority of a normal one. The scheduler will run normal processes only when there is no real-time process in the executable state.

Engine

Node Control Program Time t1

Time t2

The simulation engine sets a traffic generator as a real-time process when forking it. At the same time, the simulation engine is still a normal process. In other words, the traffic generator’s priority is always higher than the simulation engine.

Therefore, only when all of traffic generators both get blocked in the kernel mode, the simulation engine will be able to get CPU control.

In view of this, while simulation engine get the CPU control, all Node Control Program get blocked in select for socket between simulation engine and itself. As soon as Simulation Engine sends any information to Node Control Program, Node Control Program will get control immediately.

This was equivalent to saying that Simulation Engine’s notification packet which sends from simulation engine to Node Control Program let Node Control Program get control of CPU. Therefore, we can let notification packet to query how many commands which Node Control Program will send to Simulation Engine. The query result will respond to Simulation Engine in the form of ACK packet. As soon as Simulation Engine receives ACK packet which contains nonzero ACK number, it will wait Node Control Program instead of advancing simulation clock. Figure 5.2.2.2.2 shows this scenario.

However, there is a problem as Figure 5.2.2.2.3 shows. In the Figure 5.2.2.2.4, it describes a solution for above situation. When simulation engine receives an ACK packet with zero number, it will send a query packet to query Node Control Program how many commands it will send. At this time, if simulation engine receives corresponding ACK with zero number, we can make sure that Node Control Program will not send any more commands to simulation engine at this time. There is a further point which needs to be clarified. Readers may doubt that if Node Control Program generates another command which will send to simulation engine after it responds ACK packet which corresponding to query packet just like Figure5.2.2.3.3.

In fact, query packet is different from notification packet. The latter is used for simulation engine to notify Node Control Program, it may influence Node Control Program. For example, the Simulation Engine sends a notification packet which tells node that has collided into obstacle, while Node Control Program receives this packet;

it may change its direction, speed etc. Therefore, it causes Node Control Program to generate another packet. However, query packet is just like a god packet which doesn’t carry any information except query if Node Control Program will send any command in the future. In view of this, query packet will not influence Node Control Program’s behavior and decision, so Node Control Program will not generate other commands after receiving this kind of packet.

Figure 5.2.2.2.2 Communication between Engine and Node Control Program

Engine

Node Control Program Time t1

Notify packet

ACK Num=2

At this time, the simulation engine knows N.C.P. will send two more packets, so it will wait instead of advancing its simulation clock The number of the packets to be

sent in the future is 2

Figure 5.2.2.2.3 Communication between Engine and Node Control Program

Figure 5.2.2.2.4 Communication between Engine and Node Control Program

The number of the packets to be sent in the future is 0

At this time, the simulation engine knows N.C.P.

will not send packets so it will advance simulation clock.

But after N.C.P sends ACK packet, it generates two packets to send at virtual time t1, this situation results in this two packets will send at incorrect virtual time.

The number of the packets to be sent in the future is 0