In a wireless simulation with omnet++ inet 3.6, how can I manage sensor nodes to send the packets to the nearest mobile nodes? There are several sensor and mobile nodes in the field and thus cannot choose a specific destination like *.host[*].udpApp[0].destAddresses="host[0]"
Thanks for your answer.
If you have specific needs in the behavior of the application you are using, you need to implement that application. I assume you want to send UDP traffic (as TCP is connection oriented). Take a look at UdpBasicApp and modify it in a way that instead of reading the destination address once during the initialization, it must calculate the destination IP on each new packet (based on the position of nodes).
Related
I am wondering how to monitor a node in manet that whether it forwards data packets or not?
The monitoring node works as a watchdog.
My objective is to detect selfish nodes (refuse to forward packets) in a distrubited manner.
Thank you in advance!
I am using mixim and built a network including 10 nodes based on MAC 802.11.
I intend to change the transmission range of two nodes with Tx range = 200, and the other 8 nodes have Tx range = 300. I know to change Tx range of nodes, I should change Tx power in Phy layer and connection manager.
But, If I change the values, the transmission range of all the nodes will change because all the nodes use the same connection manager. Moreover, because all the nodes should have connections with others, I think I cannot use different connection managers.
In brief, I intend to change the Tx range of specific nodes (not all) in the network with same configuration, while all the nodes have connections together.
Thank you for your response.
What you are trying to set in the connection manager is the maximum interference range which has almost nothing to do with the range where radios are actually can successfully receive each other's packet. That seems to be only an optimization parameter. PhyLayer modules are present in each node, so those power parameters can be set independently for each, but you will have a HARD time figuring out, what power you should set, to get a specific distance (like 200m).
I advise you NOT to use MiXiM (and let it rest in peace), as it is a long abandoned project and all the functionality in it was merged long ago into the INET Framework.
In INET framework, you can set up UnitDisc radios, where you actually can set a transmission range in meters.
Check the wireless tutorial: https://inet.omnetpp.org/docs/tutorials/wireless/doc/step3.html
I develop simulator of mobile nodes, each one with transmission range of 100m for example. The communication between the nodes are wireless and TDMA based.
I have notice that if 2 nodes (not in the same range) broadcast message on the same time, it's cause to a problem.
How can i limit the distance of nessage that is sent from a node ? such that i can broadcast 2 or more messages on the same time, and just the nodes in the range of the sending node will hear the message ?
The code that processes the reception of the packet should calculate the distance from the sender and drop the packet if it's out of range.
A little less accurate solution: before sending the packets the broadcasting node should check the distance to the potential receiving node and not send the packet if it is out of range. This is a bit faster (as it generates less packets) and more clear (you will see the broadcast animation only for the packets that actually delivered)
A much easier solution: Use INET Framework, which already has the necessary implementation. You would only need to implement a MAC module that handles the TDMA protocol.
I have a base station and a sensor node. I want to establish communication between these two. The base station should poll the sensor node requesting temperature data captured by the sensor node. The sensor node replies with the temperature data to the base station. I can confirm that the base station and sensor node are in relative proximity to send/receive the data.
I want to write a code in nesC which can programmatically do this. Where can I find a good guide to do this?
Specifications:
Sensors- MTS400
Programming board- MIB520
Mote: Iris
You can read the TinyOS tutorials about various subjects here:
http://tinyos.stanford.edu/tinyos-wiki/index.php/TinyOS_Tutorials
Oscilloscope is an example application included in TinyOS distribution that performs what you are trying to do. You can read the code in apps/Oscilloscope.
See also some help on installing and using Oscilloscope here:
I'm working on creating a version of Pastry natively in Go. From the design [PDF]:
It is assumed that the application
provides a function that allows each Pastry node to determine the “distance” of a node
with a given IP address to itself. A node with a lower distance value is assumed to be
more desirable. An application is expected to implements this function depending on its
choice of a proximity metric, using network services like traceroute or Internet subnet
maps, and appropriate caching and approximation techniques to minimize overhead.
I'm trying to figure out what the best way to determine the "proximity" (i.e., network latency) between two EC2 instances programmatically from Go. Unfortunately, I'm not familiar enough with low-level networking to be able to differentiate between the different types of requests I could use. Googling did not turn up any suggestions for measuring latency from Go, and general latency techniques always seem to be Linux binaries, which I'm hoping to avoid in the name of fewer dependencies. Any help?
Also, I note that the latency should be on the scale of 1ms between two EC2 instances. While I plan to use the implementation on EC2, it could hypothetically be used anywhere. Is latency generally so bad that I should expend the effort to ensure the network proximity of two nodes? Keep in mind that most Pastry requests can be served in log base 16 of the number of servers in the cluster (so for 10,000 servers, it would take approximately 3 requests, on average, to find the key being searched for). Is the latency from, for example, EC2's Asia-Pacific region to EC2's US-East region enough to justify the increased complexity and the overhead introduced by the latency checks when adding nodes?
A common distance metric in networking is to count the number of hops (node-hops in-between) a packet needs to reach its destination. This metric was also mentioned in the text you quoted. This could give you adequate distance values even for the low-latency environment you mentioned (EC2 “local”).
For the go logic itself, one would think the net package is what you are looking for. And indeed, for latency tests (ICMP ping) you could use it to create an IP connection
conn, err := net.Dial("ip4", "127.0.0.1")
create your ICMP package structure and data, and send it. (See Wikipedia page on ICMP; IPv6 needs a different format.) Unfortunately you can’t create an ICMP connection directly, like you can with TCP and UDP, thus you will have to handle the package structure yourself.
As conn of type Conn is a Writer, you can then pass it your data, the ICMP data you defined.
In the ICMP Type field you can specify the message type. Values 8, 1 and 30 are the ones you are looking for. 8 for your echo request, the reply will be of type 1. And maybe 30 gives you some more information.
Unfortunately, for counting the network hops, you will need the IP packet header fields. This means, you will have to construct your own IP packets, which net does not seem to allow.
Checking the source of Dial(), it uses internetSocket, which is not exported/public. I’m not really sure if I’m missing something, but it seems there is no simple way to construct your own IP packets to send, with customizable header values. You’d have to further check how DialIP sends packages with internetSocket and duplicate and adapt that code/concept. Alternatively, you could use cgo and a system library to construct your own packages (this would add yet more complexity though).
If you are planning on using IPv6, you will (also) have to look into ICMPv6. Both packages have a different structure over their v4 versions.
So, I’d suggest using simple latency (timed ping) as a simple(r) implementation and then add node-hops at a later time/afterwards, if you need it. If you have both in place, maybe you also want to combine those 2 (less hops does not automatically mean better; think long overseas-cables etc).