I require an approach that whenever the one of host nodes in the following NED scenario receives a message or packet, a function like handlemessage is called. I want to extend a simple or compound module from AdhocHost in the Inet, for example, called Txc1 with all AdhocHost properties. Is it even possible to extend this mentioned simple module outside the Inet directories and subdirectories?
How can I reach this goal? How to code it in NED file, h, and cc files of this module?
My NED file for the network is as:
import inet.environment.common.PhysicalEnvironment;
import inet.networklayer.configurator.ipv4.Ipv4NetworkConfigurator;
import inet.node.inet.AdhocHost;
import inet.physicallayer.ieee80211.packetlevel.Ieee80211DimensionalRadioMedium;
import inet.visualizer.integrated.IntegratedVisualizer;
network Net80211
{
parameters:
int numHosts;
#display("bgb=600,400;bgi=background/terrain");
#signal[packetSent](type=inet::Packet);
#signal[packetReceived](type=inet::Packet);
#statistic[packetSent](title="packets sent"; source=packetSent; record=count,"sum(packetBytes)","vector(packetBytes)"; interpolationmode=none);
#statistic[packetReceived](title="packets received"; source=packetReceived; record=count,"sum(packetBytes)","vector(packetBytes)"; interpolationmode=none);
#statistic[throughput](title="throughput"; unit=bps; source="throughput(packetReceived)"; record=vector);
#signal[reqStreamBytes](type=long);
#statistic[reqStreamBytes](title="requested stream bytes"; record=count,sum,vector; interpolationmode=none);
#statistic[rcvdPkLifetime](title="received packet lifetime"; source="dataAge(packetReceived)"; unit=s; record=stats,vector; interpolationmode=none);
#statistic[rcvdPkSeqNo](title="received packet sequence number"; source="appPkSeqNo(packetReceived)"; record=vector; interpolationmode=none);
submodules:
visualizer: IntegratedVisualizer {
parameters:
#display("p=640,15;is=s");
}
configurator: Ipv4NetworkConfigurator {
parameters:
#display("p=640,112;is=s");
}
radioMedium: Ieee80211DimensionalRadioMedium {
parameters:
#display("p=638,56;is=s");
}
host[numHosts]: AdhocHost {
parameters:
#display("r=,,#707070;p=300,200;is=s");
}
stModule: StModule {
#display("p=639,169;i=block/cogwheel;is=s");
}
globalListener: GlobalListener {
#display("p=67,128");
}
}
Notes:
stModule is a simple module, for writing results in the finish function.
As an approach, if a new module extends from AdhocHost and it is able to trigger its own handlemessage function, it is replaced instead of AdhocHost.
As my rule, that function should be defined at the network layer. It is better to have a similar function in the data link layer, too.
A similar and simple question is in A new module that inherit from AdhocHost in omnet++. Although I test this approach, it has a problem(not call handlemessage).
Thanks in advance
Related
Assuming I want to return an instance of a "stateful" component to a user, what is the typical way I can cleanup/join background work within that instance? And are there any patterns to avoid viral propagation of explicit cleanup functions all the way to the root code?
For example, let's assume I am returning a client to a database to the user. In this client, I have a loop that periodically polls the server for updates. Now any time this exists within an ownership DAG (like as a member variable in another struct, or as a list in another struct). Requiring an explicit Close() will bubble up virally throughout the call stack. As each upwards link in the DAG will require a Close() as well. All the way to the function that owns the root instance (eg. main() will be required to call Close() on the root server instance, which will require an implementation of Close() so it cleans up background behind itself, etc). Something like the below
type DbClient struct { ... }
func Cleanup(client DbClient) { ... }
type Component struct {
client DbClient
...
}
func Cleanup(component Component) { ... }
type Server struct {
component Component
...
}
func Cleanup(server Server) { ... }
Is there any other way to handle these cases? Or is an explicit Close() function the recommendation for such stateful components?
I guess the problem you mentiond: "upwards link in the DAG will require a Close()" & "all the way to the func that owns root instance.
Go has struct embedding feature. Go favors composition over inheritance.
There's an important way in which embedding differs from subclassing. When we embed a type, the methods of that type become methods of the outer type, but when they are invoked the receiver of the method is the inner type, not the outer one.
package main
import "fmt"
type DbClient struct{}
func (client *DbClient) Cleanup() {
fmt.Println("Closed called on client")
}
type Component struct {
*DbClient
}
type Server struct {
*Component
}
func main() {
client := DbClient{}
component := Component{&client}
server := Server{&component}
server.Cleanup()
}
Suppose I have a simple module Client defined in Client.ned along with two subclassed simple modules:
simple Client
{
parameters:
volatile int clientId;
}
simple ClientA extends Client
{
}
simple ClientB extends Client
{
}
Now what I wish to do is define a network Network with 1000 ClientA instances and 1000 Client 2 instances as its submodules. I would like each instantiation to have a clientId one bigger than the last, i.e I would like the clientId parameter to ascend with each instantiation. For example, suppose we have the following Network.ned file:
network Network
{
submodules:
clientA[1000]: ClientA {
clientId = index;
};
clientB[1000]: ClientB {
clientId = 1000 + index;
}
}
What I'm looking for is a general approach, where we don't know the number of clients that are to be instantiated beforehand or even the number of client subclasses, just that if there is an instantiated Client of some sort, it should have a clientId parameter one larger than the last instantiation.
Remove volatile from clientId declaration in Client.ned and your solution will work properly.
The main purpose of using volatile is to guarantee returning a "fresh" value of a parameter when it is reading several times. In your network the clientId is constant, so the volatile is not necessary. The side-effect of using volatile is problem with using index, and parentIndex.
Beside the above, one should be aware that using omnetpp.ini is a very convenient method of control the simulation. For example, your NED files may look like:
simple Client {
parameters:
int clientId;
}
simple ClientA extends Client { }
simple ClientB extends Client { }
network Network {
submodules:
clientA[1000]: ClientA;
clientB[1000]: ClientB;
}
And the parameters may be set in omnetpp.ini:
**.clientA[*].clientId = index()
**.clientB[*].clientId = 1000 + index()
EDIT
When the number of clients is not known sizeof() method may be used to determine this number:
**.clientA[*].clientId = index()
**.clientB[*].clientId = sizeof(clientA) + index()
Since OMNeT++'s simulator assigns an ascending ID's to every module and submodule, utilizing getId(), getIndex(), getVectorSize(), and getParentModule() allows me to access this info for each module.
I have a question regarding NGXS Store and the usage of memoized #Selector()s in a state class hierarchy.
What would be the recommended approach to the issue described below?
The NGXS Store documentation does not provide a guideline/recommendation in this regard.
Given this sample state setup,
export interface BaseModel { data: string[]; }
// base class not a state!
export class BaseState {
#Selector()
static dataSelect(state: BaseModel) { return state.data; }
// ...
}
export interface DerivedModel extends BaseModel {}
#State<DerivedModel>({ name: 'derived'; })
export class DerivedState extends BaseState {
// ...
}
export interface UsingModel { thing: number; }
#State<UsingModel>({ name: 'using'; })
export class UsingState implements NgxsOnInit {
constructor(private _store: Store) {}
ngxsOnInit(ctx: StateContext<UsingModel>) {
// have this state update when derived state changes
this._store.select(DerivedState.dataSelect).subscribe(data => console.log(data));
}
// ...
}
When letting this piece of code run it will print out undefined because the state argument
of the dataSelect(...) method will not be set.
I tracked the cause to BaseState not being a NGXS State and therefore missing an internal NGXS_META
property which in turn causes the undefined argument.
Adding BaseState to the selector (such as #Selector([BaseState])) to force the state to still be
included also does not have the desired effect, because now NGXS cannot navigate to a matching state slice.
I found two ways to make this work as desired:
1. duplicate the #Selector(...) method in every derived state implementation. This though defeats the reasons why the state class hierarchy was originally designed.
2. use something like #DerivedSelector(...) that works according to the standard decorator but dynamically creates selectors on use for each of the encountered derived state classes.
Thank you.
As far as I know this can not be achived using the #Selector annotation, but with createSelector().
export class BaseState {
static dataSelect() {
return createSelector(
[this],
(state: BaseModel) => {
return state.data;
}
);
}
//...
}
If you change your base state like this, your code will work. For details refer to the NGXS docs
Iam trying to create simple wireless node for MANET network which can send messages to other nodes in range. Solutions implemented in INET also contains other layers like IP, transport, application which i dont need.
Iam new to omnet++ so iam struggling a bit. I was thinking of creating whole own node with RadioIn input, but i dont know how to implement only in range communication and i will also need node mobility.
Other solutions would be to use only Radiomedium from INET framework but i dont know how to do it.
Can someone please give me some begginer tips how to achieve my goal? As i said i simply need to create mobile host which can send a defined message to all other hosts in range.
EDIT: I tried to take IdealRadioMedium and create my simple module and connect to it. Here is the NED File.
import inet.physicallayer.common.packetlevel.Radio;
import inet.common.figures.DelegateSignalConfigurator;
import inet.networklayer.configurator.ipv4.IPv4NetworkConfigurator;
import inet.node.inet.INetworkNode;
import inet.node.inet.WirelessHost;
import inet.physicallayer.contract.packetlevel.IRadioMedium;
import inet.visualizer.integrated.IntegratedCanvasVisualizer;
import inet.linklayer.contract.IWirelessNic;
import inet.networklayer.common.InterfaceTable;
simple Txc1
{
gates:
input in;
output out;
}
module Pokusny
{
parameters:
#display("i=device/wifilaptop");
int numRadios = default(1);
#networkNode;
gates:
input radioIn[numRadios] #directIn;
submodules:
mynode: Txc1;
wlan[numRadios]: <default("Ieee80211Nic")> like IWirelessNic {
parameters:
#display("p=216,406,row,60;q=queue");
}
interfaceTable: InterfaceTable {
parameters:
#display("p=53,300;is=s");
}
connections allowunconnected:
for i=0..sizeof(radioIn)-1 {
radioIn[i] --> { #display("m=s"); } --> wlan[i].radioIn;
wlan[i].upperLayerOut --> mynode.in;
wlan[i].upperLayerIn <-- mynode.out;
}
}
network WirelessC
{
parameters:
string hostType = default("WirelessHost");
string mediumType = default("IdealRadioMedium");
#display("bgb=650,500;bgg=100,1,grey95");
#figure[title](type=label; pos=0,-1; anchor=sw; color=darkblue);
#figure[rcvdPkText](type=indicatorText; pos=420,20; anchor=w; font=,20; textFormat="packets received: %g"; initialValue=0);
#statistic[rcvdPk](source=hostB_rcvdPk; record=figure(count); targetFigure=rcvdPkText);
#signal[hostB_rcvdPk];
#delegatesignal[rcvdPk](source=hostB.udpApp[0].rcvdPk; target=hostB_rcvdPk);
submodules:
visualizer: IntegratedCanvasVisualizer {
#display("p=580,125");
}
configurator: IPv4NetworkConfigurator {
#display("p=580,200");
}
radioMedium: <mediumType> like IRadioMedium {
#display("p=580,275");
}
//figureHelper: DelegateSignalConfigurator {
// #display("p=580,350");
//}
hostA: Pokusny {
#display("p=50,325");
}
hostB: Pokusny {
#display("p=450,325");
}
}
Txc1.cc
class Txc1 : public cSimpleModule
{
protected:
// The following redefined virtual function holds the algorithm.
virtual void initialize() override;
virtual void handleMessage(cMessage *msg) override;
};
// The module class needs to be registered with OMNeT++
Define_Module(Txc1);
void Txc1::initialize()
{
cMessage *msg = new cMessage("tictocMsg");
send(msg, "out");
}
void Txc1::handleMessage(cMessage *msg)
{
send(msg, "out"); // send out the message
}
And .ini file
network = WirelessC
sim-time-limit = 25s
*.host*.wlan[0].typename = "IdealWirelessNic"
*.host*.wlan[0].mac.useAck = false
*.host*.wlan[0].mac.fullDuplex = false
*.host*.wlan[0].radio.transmitter.communicationRange = 500m
*.host*.wlan[0].radio.receiver.ignoreInterference = true
*.host*.**.bitrate = 1Mbps
When i run the simulation it asks for Interfacetable parameter which i dont know what to type there becuse i havent found it in traversing functioning code ( I had to add it because it throws error that is missing if its not as submodule). Now iam getting
getCointainingNode() node module not found it should have a property name networkNode for module WirelessC.interfaceTable in module .... durint network initialization
EDIT: I added networknode as parameter and now i got Module not found on path '.mobility' defined by par WirelessC.hostA.wlan[0].radio.antenna.Mobilitymodule in module inte::physicallayer:IsotropicAntenna during network initialization
I'd like to point you to the wireless tutorial for INET: https://omnetpp.org/doc/inet/api-current/tutorials/wireless/
It starts with exactly your problem. The only thing left, is to replace the standard UDP host with a host using no protocol at all, maybe even implementing your own. The whole wireless part is explained in the tutorial.
If you want to check the source files for the used modules you need to walk down the chain of dependency since every compound NED module will (at one point) contain simple modules implemented in C++.
E.g. the module which is responsible for distributing the signals is IdealRadioMedium using RadioMedium. Now you need to find the Node implementation directly communicating with this module.
Starting with the WirelessHost used in the tutorial the underlying modules are
StandardHost -> ApplicationLayerNodeBase -> LinkLayerNodeBase with the later being the first one using actually implemented submodules.
The network adapter used is configured in the omnet.ini with *.host*.wlan[0].typename = "IdealWirelessNic". This module relies on Radio.
With all that found out you just need to look for API calls from Radio.cc made to RadioMedium.cc and you found the actual code responsible for sending data.
Understanding that chain of inheritance you can even hook in with your custom module at a level you find fitting. For example just implementing your own LinklayerNodeBase module.
If you are going for wireless communication and mobility, INET will still be the best framework to use.
Check out the INET Wireless Tutorial. It basically covers all the steps that you need to build a small scenario with moving nodes that communicate wirelessly.
I want to implement the UDPBASICBurst app in Veins, but I am facing problems. I have done as follows but I don't know if I am correct. Can anybody put light on this matter?
import inet.applications.udpapp.UDPBasicBurst;
import org.car2x.veins.base.modules.*;
import org.car2x.veins.modules.nic.Nic80211p;
....
udpBasicBurst: UDPBasicBurst {
#display("p=130,56");
}`enter code here`
connections allowunconnected:
nic.upperLayerOut --> appl.lowerLayerIn;
nic.upperLayerIn <-- appl.lowerLayerOut;
nic.upperControlOut --> appl.lowerControlIn;
nic.upperControlIn <-- appl.lowerControlOut;
veinsradioIn --> nic.radioIn;
udpBasicBurst.udpOut --> nic.upperControlIn;
udpBasicBurst.udpIn <-- nic.upperControlOut;
}
import inet.applications.udpapp.UDPBasicBurst;
import org.car2x.veins.base.modules.*;
import org.car2x.veins.modules.nic.Nic80211p;
module Car
{
parameters:
string applType; //type of the application layer
string nicType = default("Nic80211p"); // type of network interface card
string veinsmobilityType; //type of the mobility module
gates:
input veinsradioIn; // gate for sendDirect
submodules:
appl: <applType> like org.car2x.veins.base.modules.IBaseApplLayer {
parameters:
#display("p=60,50");
}
nic: <nicType> like org.car2x.veins.modules.nic.INic80211p {
parameters:
#display("p=60,166");
}
veinsmobility: <veinsmobilityType> like org.car2x.veins.base.modules.IMobility {
parameters:
#display("p=130,172;i=block/cogwheel");
}
udpBasicBurst: UDPBasicBurst {
#display("p=130,56");
}
connections allowunconnected:
nic.upperLayerOut --> appl.lowerLayerIn;
nic.upperLayerIn <-- appl.lowerLayerOut;
nic.upperControlOut --> appl.lowerControlIn;
nic.upperControlIn <-- appl.lowerControlOut;
veinsradioIn --> nic.radioIn;
udpBasicBurst.udpOut --> nic.upperControlIn;
udpBasicBurst.udpIn <-- nic.upperControlOut;
}
You are importing both inet.applications.udpapp.UDPBasicBurst and org.car2x.veins.modules.nic.Nic80211p in the same module. This will likely not work the way you hope:
Simply speaking, modules in the inet.* namespace only expect to exchange messages with other modules from this namespace. Up to and including Veins 4a2, the same goes for modules in the org.car2x.veins.* namespace - with one notable exception: The Veins 4a2 TraCIScenarioManager will check if an instantiated module uses an inet 2.3.0 TraCIMobility module as their mobility submodule. If it does, it will move the module accordingly.
This allows you to use Veins 4a2 mobility in INET 2.3.0 hosts.