Tags:
create new tag
, view all tags
Modularity in WiSeNeT in short means that each layer of the testbed is able to operate independently of the other layers. Furthermore, other key components such as statistics are defined and grouped together in separate files. Changes can therefore be made to layers and components without affecting the overall operation of the testbed.

Each layer is written as a separate class that can be called from the main program. Within these classes are predefined threads to manage the various functions. These threads are created only when the layer is instantiated from the main program. For example, if the test packet function is chosen, then the network and application layers are not instantiated, therefore their threads are never created; the link layer is instantiated, and as such, its threads are created. WiSeNeT manages this instantiation in the main program, based on the arguments presented at the command line.

Threads created within layers are privy to that layer’s (class’) variables (through use of the self variable) as well as variables that have been imported into the testbed through the import statement (this includes the global variables specified in global_variables.py). As they are within a class instantiated from the main program, they are therefore not privy to any other layer’s (class’) variables – for example, functions defined in the link layer cannot be accessed by any other layer.

In order for layers to communicate with each other, the following interfaces have been defined for the testbed (Figure 4):

f4.png

Figure 4: WiSeNeT interface specifications

All the queues above except for inbound_buffer are of type Queue.Queue(). The reason why Queue.Queue() was selected was due to its thread-safe capability, as well as the ability to set a maximum size and its blocking capabilities. They are all defined as passive queues, and require an active thread to pull the data from them – polling is used in order to put the data on the queue if there is space through put_nowait() or get the data if there is any through get_nowait(). The alternative is to have the thread blocking and waiting for the queue to have space or for something to arrive at the queue – this is an indefinite wait() and is much more difficult to program and have the thread return from the wait() condition.

Due to the way the serial port is read, the inbound_buffer queue is defined as a list because of its flexibility in slicing. The information required to be passed into the queues are defined as per Figure 4 above. Note that the complete packet is not passed through all the layers – because of the way encapsulation works, each layer decodes its relevant parts of the packet, and passes the required information to the next layer. There are some extra queues defined in the interface specification as well, which are not necessary to operate the base implementation of WiSeNeT:

  • LL_speed is a queue to provide the network layer capability to change the link layer rate (useful for congestion control algorithms).
  • child_information_queue is a way the link layer can pass information about all active children up to the network layer for LVCC calculations.
Topic revision: r5 - 2012-01-20 - XiaohongWu
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback