I am simulating a Flying Ad Hoc Network using aodv routing protocol. I want to get the list of neighbor's node to send random numbers to these neighbors. I found this code in google omnet++ forum :
#include "IRoutingTable.h"
#include "RoutingTableAccess.h"
vector<IPAddress> neigh;
IRoutingTable *inet_rt = RoutingTableAccess().get();
neigh.clear();
for (int i=0;i<inet_rt->getNumRoutes(); ++i)
{
const IPRoute *e = inet_rt->getRoute(i);
if (e->getMetric()==1)
{
neigh.push_back(e->getHost());
}
}
But when i try to use it, i can't find the file "RoutingTableAccess.h" in the inet directory? Is there any other method to get the list of neighbors in Mobile Ad hod Network using aodv?
Many Thanks.
Since INET 4.0 every host has the parameter routingTableModule that indicates the name of routing table's module.
The following method may be used to obtain an access to routing table:
IRoutingTable *routingTable;
routingTable = getModuleFromPar<IRoutingTable>(par("routingTableModule"), this);
Related
Is it possible to detect which network (testnet, mainnet etc..) your contract is in via, for example, env in Rust? I have a contract that will be deployed to both testnet and mainnet and I have logic that depends on the network.
There are a two things you can do in this case that I could think of.
You could store in the state of the contract which network it lives on and then pass that into the initialization function.
If you wanted to use env, you could right split env::current_account_id() and check for .testnet at the end of the account ID.
Note: This method won't work if your contract is deployed to an implicit account.
An example of the code is:
// Get this with env::current_account_id();
let str = "benji.testnet.fayyr.testnet".to_string();
// Get the split at the end of the string using `.testnet`
let split_check = str.rsplit_once(".testnet");
// Default network to mainnet
let mut network = "mainnet";
// If `.testnet` was found, make sure it was at the end of the account ID
if let Some(split) = split_check {
if split.1.len() == 0 {
network = "testnet";
}
}
I want to browse a specific node on my OPC UA Server and use its method.
I use the open62541 stack and i want to use a selfmade client. My Client connects to the Server and then i use the given example to browse some Objects. It shows me the first layer of nodes after the root-folder-
How can i find a specific node? Or have i to browse to this point? Is there an example file in the open62541 project which i don't see that would open my eyes?
I also find the Method "Service_TranslateBrowsePathsToNodeIds" but i'm not quite sure how to use it the right way and which part is interesting for me.
As an example:
I want to browse the Node "FileSystem", which is in a deeper layer than the root-folder, and want to use its Method createFile.
To call a method, you need two node ids:
Object node id which contains the method
Method node id
If you already have these node ids, you can call the method right away. If not,
OPC UA in general supports two options to get these node ids:
Start at the root node (ns=0;i=84) and recursively browse all the child nodes until you find the node with the specific browse name.
https://github.com/open62541/open62541/blob/58bd161557111847d068650eff5ad670a9aa0395/examples/client.c#L61
Use the TranslateBrowsePathsToNodeIds Service if you have a browse path. I.e., give /Objects/MyDevice/FileSystem/UploadFile (concatenation of browse names) with start node Root (ns=0;i=84) and the server will return you the node id of that specific node if it exists. This service is taking relative paths, therefore you can also use other nodes as start nodes
https://github.com/open62541/open62541/blob/58bd161557111847d068650eff5ad670a9aa0395/examples/client_async.c#L183
After some trial and error I found the 'magic' bits to get it working with nodes that are in the server namespace, e.g. of real devices and not pre-defined UA nodes like timestamp or server status as shown in all examples. The code below is derived from the corpus_generator.c and check_services_view.c files of Open62541 with 2 key differences:
You do not have to specify the referenceTypeId.
When creating the strings, place them in the server namespace, not UA namespace (see UA_QUALIFIEDNAME_ALLOC below).
The function below will take a pointer to UA_Client and a vector of browsenames that form the path to the node, starting at the Objects folder in OPC-UA.
Node::Node (UA_Client *client, const std::vector<std::string> &browse_path)
: m_client (client)
{
m_id = UA_NODEID_NULL;
// Search for ID in client
UA_BrowsePath browsePath;
UA_BrowsePath_init (&browsePath);
browsePath.startingNode = UA_NODEID_NUMERIC (0, UA_NS0ID_OBJECTSFOLDER);
browsePath.relativePath.elements = (UA_RelativePathElement *)UA_Array_new (browse_path.size (), &UA_TYPES[UA_TYPES_RELATIVEPATHELEMENT]);
browsePath.relativePath.elementsSize = browse_path.size ();
for (int i = 0; i < browse_path.size (); i++)
{
UA_RelativePathElement *elem = &browsePath.relativePath.elements[i];
elem->targetName = UA_QUALIFIEDNAME_ALLOC (1, browse_path.at (i).c_str ()); // Create in server namespace (1), not UA namespace (0)!
}
UA_TranslateBrowsePathsToNodeIdsRequest request;
UA_TranslateBrowsePathsToNodeIdsRequest_init (&request);
request.browsePaths = &browsePath;
request.browsePathsSize = 1;
UA_TranslateBrowsePathsToNodeIdsResponse response;
response = UA_Client_Service_translateBrowsePathsToNodeIds (m_client, request);
if (UA_STATUSCODE_GOOD == response.responseHeader.serviceResult && response.resultsSize > 0)
{
UA_BrowsePathResult *first = response.results;
if (first->targetsSize >= 1)
{
m_id = first->targets[0].targetId.nodeId;
std::cout << "Found ID";
}
else
{
std::cout << "OK response but no results";
}
}
else
{
std::cout << "Error in translate browsename";
}
UA_BrowsePath_deleteMembers (&browsePath); // Marked as deprecated, but UA_BrowsePath_delete() expects a heap-allocated pointer.
UA_TranslateBrowsePathsToNodeIdsResponse_deleteMembers (&response); // Idem
}
Good Morning!
I'm implementing a simulation for a dynamic distributed storage network, which requires at certain points, that the connections between the modules vary. (e.g. client connects to a node (establishes a new connection) and wants to work with his data, stored on different nodes).
Is there is possibility to establish connections between unconnected but existing gates of two nodes at runtime?
For example:
simple node1 {
parameters:
#display(...);
gates:
input in #loose;
output out #loose;
}
simple node2 {
parameters:
#display(...);
gates:
input in #loose;
output out #loose;
}
Afterwards there would be a boring network definition with no connections. (Don't know if it is possible to have a completely blank definition, but for the minimal example we assume it)
In the C++ file for the modules I wish to create a connection between these nodes depending on a certain condition like (pseudo code):
if(condition){
node1->setConnection(ownGate("out"),node2->getGates("in"),true);
}else{
node1->setConnection(ownGate("out"),node2->getGates("in"),false);
}
I've read the simulation manual of Omnet++ but really can't figure out what to do here ...
Is it possible at all to do this? And how?
Thanks for any help here!
Yes, it is possible to dynamically create a connection between two modules. One may use connectTo() method to do it.
Assuming that the network contains two nodes of both types from your question:
network Test1 {
submodules:
n1 : node1;
n2 : node2;
}
the following code may be used to connect n1 to n2 using bidirectional connection:
// code of n1
if(condition) {
cModule * dest = getModuleByPath("n2");
cGate * destGateIn = dest->gate("in");
cGate * thisGateOut = gate("out");
thisGateOut->connectTo(destGateIn); // forward direction
cGate * destGateOut = dest->gate("out");
cGate * thisGateIn = gate("in");
destGateOut->connectTo(thisGateIn); // reverse direction
}
I am reading about the Linux Device model which is built around buses,devices and drivers
.I am able to understand a bit about how devices and driver matches happen but not clear about the role of buses here,how buses matches with device.
One more doubt I have regarding where platform device gets it name from.
"The platform bus,simply compares the name of each device against the name of each driver; if they are the same, the device matches the driver."
Now I could n't really understand above point .I believe device name is first defined in dts file and then corresponding Driver name is defined in platform driver code .
if these two name matches ,probe is called from driver code which will confirm device is really in existence.
Could anybody let me know the whole process specially from Bus point of view.
To add to #Federico's answer, which describes very well the general case, platform devices can be matched to platform drivers using four things (that are prioritized). Here is the match function of the platform "bus":
static int platform_match(struct device *dev, struct device_driver *drv)
{
struct platform_device *pdev = to_platform_device(dev);
struct platform_driver *pdrv = to_platform_driver(drv);
/* Attempt an OF style match first */
if (of_driver_match_device(dev, drv))
return 1;
/* Then try ACPI style match */
if (acpi_driver_match_device(dev, drv))
return 1;
/* Then try to match against the id table */
if (pdrv->id_table)
return platform_match_id(pdrv->id_table, pdev) != NULL;
/* fall-back to driver name match */
return (strcmp(pdev->name, drv->name) == 0);
}
Here are two important ones.
OF style match
Match using the device tree (of_driver_match_device). If you don't know the device tree concept yet, go read about it. In this data structure, each device has its own node within a tree representing the system. Each device also has a compatible property which is a list of strings. If any platform driver declares one of the compatible strings as being supported, there will be a match and the driver's probe will be called.
Here's an example of a node:
gpio0: gpio#44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x44e07000 0x1000>;
interrupts = <96>;
};
This describes a GPIO controller. It only has one compatible string which is ti,omap4-gpio. Any registered platform driver declaring this same compatible string will be probed. Here's its driver:
static const struct of_device_id omap_gpio_match[] = {
{
.compatible = "ti,omap4-gpio",
.data = &omap4_pdata,
},
{
.compatible = "ti,omap3-gpio",
.data = &omap3_pdata,
},
{
.compatible = "ti,omap2-gpio",
.data = &omap2_pdata,
},
{ },
};
MODULE_DEVICE_TABLE(of, omap_gpio_match);
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
.driver = {
.name = "omap_gpio",
.pm = &gpio_pm_ops,
.of_match_table = of_match_ptr(omap_gpio_match),
},
};
The driver is able to drive three types of GPIOs, including the one mentioned before.
Please note that platform devices are not magically added to the platform bus. The architecture/board initialization will call platform_device_add or platform_add_devices, in this case with the help of OF functions to scan the tree.
Name matching
If you look at platform_match, you will see that the match falls back to name matching. A simple string comparison is done between the driver name and the device name. This is how older platform driver worked. Some of them still do, like this one here:
static struct platform_driver imx_ssi_driver = {
.probe = imx_ssi_probe,
.remove = imx_ssi_remove,
.driver = {
.name = "imx-ssi",
.owner = THIS_MODULE,
},
};
module_platform_driver(imx_ssi_driver);
Again, the board specific initialization will have to call platform_device_add or platform_add_devices to add platform devices, which in the case of name matching ones are entirely created statically in C (name is given in C, resources like IRQs and base addresses, etc.).
In the Linux kernel there are different buses (SPI, I2C, PCI, USB, ...).
Each bus has the list of drivers and devices that are registered on the bus.
Each time you connect a new device or a new driver to a bus, it starts the matching loop.
Suppose that you register a new SPI device. The SPI bus start a matching loop where it invokes the SPI match function to verify if your device match with a driver already registered in on the bus. If it does not match, there is nothing to do.
Now, suppose that you register a new SPI driver. The bus start again the matching loop in order to verify if any of the registered device match with this new driver. If it match, the driver probe() function is invoked.
Each bus has it own method to match a driver with a device. In order to implement a bus you have to write the matching function. So, you can implement a bus that match by name, by integer value, or anything you want.
You start the bus mechanism each time you register a driver or a device.
Here how I implemented the ZIO bus.
Here you can find the SPI bus
Here the core of the bus system
I'm using the oscP5 library in Processing. I've already looked in the javadoc for oscP5 and I've browsed through the source but I can't figure it out.
When I get debug info like this:
### new Client # netP5.TcpClient#2515
What does the value 2515 represent? I know it is not the port the client is using. Is it a unique id for the client? Is it a variable I can access in the TcpClient class?
Thanks.
It is the objects (TcpClient) address in memory. You find the source code at
src/netP5/AbstractTcpServer.java
TcpClient t = new TcpClient(this, _myServerSocket.accept(),
_myTcpPacketListener, _myPort, _myMode);
if (NetP5.DEBUG) {
System.out.println("### new Client # " + t);
}
This means, that your number is the String representation of TcpClient. Since nothing is implemented to return this - its the default behaviour: objects address. You can access this TcpClient object and its members as shown in to following example. I assume here for simpleness, that we look at the first object in the clients list.
if (oscP5tcpServer.tcpServer().getClients().length>0) {
TcpClient tcpClient = (TcpClient)oscP5tcpServer.tcpServer().getClient(0);
print (tcpClient); // address - same as your printed output
print (tcpClient.netAddress()); // string with "ip:port"
print (tcpClient.socket()); // Socket object
}
Please note, that most of the interesting information is contained in the base object AbstractTcpClient (as shown in the example).