Right now I am working on a project which fully depends on peer-to-peer communication (ie, no centralized server) with no internet connection. I'm studying about peer-to-peer for the last week, I came to know about the mesh network things. It seems similar to P2P.
I want to know whether the P2P is a part of the mesh networking concept or they are the same? Is there any difference between these two?
As far as my research, it's really hard for me to find the thing I want. Can anyone explain it in a simple manner? Because what am I getting all the time is the same answer without a reference on what is the relation between these two.
P2P and mesh network are usually used when referring to concepts on different network layers.
A mesh network is a topology used to organize nodes into a network that can transmit data between nodes that are not in direct physical contact with each other. Different models on the same layer would be star (e.g. local ethernet setups) or hub-spoke topologies for example.
P2P on the other hand refers how endpoints talk to each other on the application layer, i.e. they connect to each other "directly" (abstracted over the underlying network layers of course) to exchange information. It contrasts with the client-server model, where a server would act as relay or storage for the data that clients read or write.
Peer-to-peer refers to the hierarchy, that all stations are on the same level.
Mesh refers to the cabling scheme, a many-to-many network.
A peer-to-peer network may connect may use bus, ring, or mesh cabling.
A client-server network mostly uses star cabling scheme.
P2P is an overlay network on top of the Internet. The P2P protocols are on the Application layer if you are considering OSI reference model. In addition, it is a logical organization of nodes and nodes basically can communicate with each other without the need for a central node (coordinator). Therefore, the nodes need to have an Internet connection.
whereas, mesh is a physical topology (not logical topology) where each node is connected to every other node directly (of course if it is not partial mesh topology)
Related
I am using NetSim by Tetcos to simulate Wormhole attacks in IoT networks that rely on RPL as routing protocol.
To do so I need two IoT devices to communicate with each other even if they are not linked directly in the DODAG structure. Therefore my theoretical solution would be to set up a wired link between the two malicious nodes and to do so I would need to set up a second interface in the IoT device which is not available by default.
Is there anyone of you who know how to implement this or that can help me in any way?
Thank you in advance.
I solved the problem with the help of NetSim support. I was able to implement a function that modifies the routing table of the malicious node in order for it to forward all the packets (except for DIO, DAO and DIS packets) to another malicious node of my choice creating a tunnel between this two nodes.
I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
I am working on a project called sensorhub. In that, sensors needs to communicate with each other in a mesh network and need to send the data to the border router.
I found that contiki os can do the mesh network work.but i didn't know how to get started with it.
My question is,
Is there any possibility that cc26xx can be done with cooja simulator ?
If answer to the first question is No. what kind of things I need to follow to make the mesh network work with cc26xx/cc13xx?
No. You can use msp430 based platforms, such as sky or z1 in Cooja.
Contiki uses RPL for IPv6 multihop routing in order to build a single-parent routing tree on top of the mesh. The mesh network is a sort of service provided by the system, you don't need to do anything special to enable it. See contiki/examples/ipv6/ for some examples on how to send packets between nodes. These examples work in both star and mesh network topologies, as long as there's a RPL root node somewhere in the network.
We are planning to use Ethernet bus topology (wiki). The reason using this very old topology is hardware limitations and software requirements. Collisions should be OK, as bandwitdh requirement is very low.
My problem is, how can we test this topology with modern Ethernet controllers and software like Ubuntu etc. I could not find a good implementation example.
I have tried connecting three Intel Ethernet controllers (with Static IPs) together and only two of them had link at a time (they worked in point-to-point connection as usual)
"Modern" hardware is rather limited when trying to build a bus topology - it's much easier to build a more usual star/tree network. However, with the right key components you can even connect both topologies.
From the software point of view, the network just "works", i.e. as long as the network is configured correctly the software applications can (and should) be oblivious to the network layout.
With an assumed Ethernet network, the logical structure of each segment is a bus anyway: each device can just talk to any other device, regardless of where and how they are connected.
I'm new to DDD and I'm trying to decide how to access infrastructure hardware (network devices, specialized hardware, etc) information. Most of the devices I want to communicate with and control have a state. I'm representing the devices in the domain as objects but to replicate the state should it be through a repository or a service or some other component.
An example would be: If a customer buys a firewall the command AddFireWall would be executed and the vlan on a network device would be switch to a firewall and an IP and private IP would be placed on that firewall device. I'm representing the network devices and firewall devices as entity objects in my domain. The state of those objects/devices would be saved in the repository.
Generally speaking you domain models should be kept free from external dependencies like hardware and networks etc. There is a concept known as an Anti Corruption Layer that may be worth looking up. The idea is to build a bridge between systems like hardware and the domain. It's responsibility is to translate between the two systems. If hardware or network changes then all you need to adjust is the code in the ACL.
Other approaches could include generating event messages from the hardware. These messages can then be subscribed to be various parts of your system.