We are working on a project to create a V2V ad-hoc network between vehicles. Basically we are deploying Raspberry Pis in vehicles and we are using Xbee modules and Zigbee protocol in order to exchange data between vehicles if they are near from each other.
Our ad-hoc network is completely dynamic and decentralized (We cannot have any static nodes in the network). Our problem is that the topology of the mesh network created by the Zigbee protocol requires a coordinator to be always in the network and the network will fail in case this coordinator failed down.
It seems that using Zigbee protocol requires knowing the topology of the network beforehand.
We do not know whether it is feasible to create our dynamic network using the Zigbee protocol without knowing the topology of the network beforehand and without the requirement of the coordinator. Can we have more than 1 coordinator in the network to overcome this problem? Thanks in advance.
Is there a particular reason you are looking to use Zigbee? if you are after a truely decentralised network you would be better off using either a different protocol (one that has no need for a coordinator) or by defining your own using basic RF modems (which is a lot more complicated)
however XBee modules are configurable by AT commands, with a bit of work you could probably set them up to periodically change mode (when it is running as coordinator) to check for other coordinators and if it finds one then stay as a standard node, and if the coordinator drops out (stops replying) then steps up to be coordinator.
this approach would require you to solve a few issues though:
how do the remaining modules in the network decide which becomes coordinator
how often would the coordinator scan for other coordinators in order to effect a reasonable response time, yet not disrupt data flow
i would suggest that you provide a bit more information relevant to the question such as:
how much data is being transferred?
how often is this data being transferred?
how are you planning to define where the data gets sent (addresses? or multicast to everywhere?)
hopefully this helps you in the right direction, but in the mean time i'd suggest you look at the XBee datasheets for the AT commands and what is possible (has been a while since i used them)
James
Digi sells XBee modules that implement protocols other than ZigBee. Both the plain 802.15.4 module and their proprietary DigiMesh module would be possible candidates for your project if you don't need to be ZigBee-compliant.
I think that you could send broadcast messages with 802.15.4.
With DigiMesh, all nodes are of the same node type. But I do not know how well it will handle having networks come together and fragment on a regular basis. You could contact Digi's technical support or sales support teams to see if they can provide any guidance.
Related
I was wondering if DDS could be used over the internet, and if it would be a good choice for online gaming.
I have seen on the RTI website that they support WAN, but does that mean I can subscribe to a topic from another participant that is on the other side of the world?
What would happen to the QoS guarantees if this was the case?
Thanks.
Disclaimer: I work on OpenDDS full time, but have no experience in networked games programming.
A internet-enabled DDS could be used for connecting game clients. Whether or not it's a good idea is something I can't answer at the moment with no specific information, but the QoS part is a good question. In OpenDDS, as far as I'm aware, we try to adhere to the QoS defined by the user as if it was a normal RTPS connection. This means using it over the Internet might require some tuning of the QoS depending on what QoS you want to use. For example if deadline QoS was being used on a local network, the time period might have to be relaxed given the greater latency of the Internet.
For OpenDDS, internet-enabled RTPS is described in Chapter 15 of the OpenDDS's Developer's Guide: http://download.objectcomputing.com/OpenDDS/OpenDDS-latest.pdf. In addition to using ICE to overcome NATs, we also have a feature called the RTPS Relay to enable connections when a client can't use ICE.
I'm not familiar with what specific capabilities RTI Connext here has but as far as I'm aware they are similar, in that they use ICE as well. Also it should be noted that internet-enabled RTPS is not standardized, so the Connext and OpenDDS wouldn't be able to be talk over WAN.
OpenDDS would only be appropriate for games in very constrained environments because of the bandwidth requirements. If all users are on the same LAN then the UDP multicast approach that RTPS uses would be effective for a peer-to-peer game architecture. However, if remote users are added, then the requirement of every peer having to send every update directly to every other peer will very quickly explode the bandwidth requirements.
Given that the RTPS relay is already another application that needs to be run, a game server that collates updates from peers and sends world state would be far more effective for cases where users are not all on a single LAN segment.
Suppose I have a producer located on one machine and two independent consumers on the other. Consumers share the same IP. I want my data to be sent via WiFi and I want to avoid sending the same packages twice: I mean I want the packages to be replicated as late as possible -- either on router or on destination machine.
I managed to find these options:
1) Just use different ports -- in this case everything will be sent twice, but at least all consumers will get their copy of data.
2) Try to use SO_REUSEPORT -- without multicast this will make only one of two consumers get the packages.
3) Use multicast (with SO_REUSEADDR) -- I guess it is the only solution for my problem, and the packages will be replicated by router, not publisher.
I know, that there are messaging libraries and frameworks, which are supposed to be responsible for marshaling and routing, but I need "pure" UDP solution with maybe some simple logic upon it. I am not sure if I am correct with options that I mentioned, and I don't know whether there exists any more simple and suitable solution.
As people told you in the comments, one popular and efficient solution to you problem (one publisher multiple subscribers over network, aka pubsub) is to send UDP datagrams to a multicast IP address. The listeners must join that IP multicast group in order to tell the intermediate routers to forward those datagrams.
You can code it up yourself, there are plenty of examples elsewhere.
In a production setting, however, I recommend against reinventing the wheel along with associated mistakes. Have a look at existing solutions, such as ZeroMQ. It supports this messaging pattern of one publisher to multiple subscribers using UDP/IP multicast but with a nice interface, cross-language compatibility and much more. See Publish/Subscribe example in Python.
I am a beginner in Zigbee. I wanna create a mesh network of Zigbee modules in which all nodes can communicate with each other.
I found that Zigbee can be operated in different modes and each modes have its own features. I want to know that which mode will provide an effortless communication in real time applications. We want to build a system that automatically connects to the neighboring Zigbee modules and establishing a communication path to each other.
Is anyone knows about it,please give me the answer to clarify my doubts.
You can use both
Transparent mode has limited functionality and not suitable for larger networks but
API mode allows you to form larger networks and is more appropriate for creating sensor networks to perform tasks such as collecting data from multiple locations, controlling devices remotely, automating your home or for real time systems.
We're about to design an inhouse industry network consisting basically of the following: 1 server connected via wire to up to 100 proprietary RF access points (basically embedded devices), which each can be connected via radio to up to 100 endpoint embedded devices. Something like this:
Now, I'm wondering about some design decisions that we need to take and I'm sure there are plenty of similar designs out there and lots of folks with experiences of them, both good and bad. Maybe you can chime in?
All endpoint devices are independent and will communicate their own unique data to the server, and the other way around. The server therefore needs to be able to target each endpoint device individually. Each endpoint device pairs itself with 1 access point and then talks a proprietary RF protocol to it, TCP/IP is not an option there.
The server will know which endpoint device is paired with which access point, so when the server needs to talk to an individual endpoint device, the communication must go through the paired access point. Hence, the server needs to directly address the access point.
Question: Considering the limited resources available in the proprietary access point, is TCP/IP between server and access point recommended for this scenario? Or would you suggest something entirely different?
I find the diagram confusing:
If this isn't its own network and the server to AP link is running on your internal company network, there isn't really an option, there must be a TCP/IP stack on the AP.
If this is its own isolated network then what is the router for?
If this is, in fact, its own isolated network then you are right, there really isn't a need for the Ethernet connectivity at all. The overhead you will see on the wireless is huge, your no overhead ideal data rate is 250kbit/sec, running ZigBee on 802.15.4 # 2.4ghz point to point your real data throughout is usually around 20kbit/sec. A custom protocol should be able to obtain lower overhead but this would need to be defined.
If I were designing this I would choose a SoC for the AP that had on board 802.15.4 and CAN (Controller Area Network). Depending on size and data rate just get a PCI CAN card for the server and connect it up, use something like DeviceNet as your protocol layer for server to AP communications. This can be expanded by using CAN switches and repeaters. CAN is used all the time in industrial automation, a little googling can find you example of tens of thousands of nodes used in some manufacturing plants.
There are small TCP/IP stacks, for example LwIP.
You didn't mention the amount of data to be communicated, or bandwidth considerations?
A 3rd party TCPIP stack targeted at the 8051 would simplify all the networking issues with connecting 100 units. You probably will still end up with a proprietary protocol that sits on top of the tcpip stack but then it is just simple point-to-point communication between the server and each end point.
I want to develop simple Serverless LAN Chat program just for fun. How can I do this ? What type Architecture should I use?
Last year I have worked on TCP,UDP Client/ Server application Project.It was simple (Server listens to certain port/socket and Client connect to server's port etc..) But I have no idea about how to develop "Serverless" LAN Chat program. How can I do this? UDP,TCP,Multicast,Broadcast? or Should program behave like both server and client?
The simplest way would be to use UDP and simply broadcast your messages all over the network.
A little bit more advanced version would be to only use the broadcast to discover other nodes in the network.
Every node maintains a list of known peers.
Messages are sent with TCP to all known peers.
When a node starts up, it sends out an UDP broadcast to discover other nodes.
When a node receives a discovery broadcast, it sends "itself" to the source of the broadcast, in order to make it self known. The receiving node adds the broadcaster to it's own list of known peers.
When a node drops out of the network, it sends another broadcast in order to inform the remaining nodes that they should remove the dropped client from their list.
You would also have to consider handling the dropping out of nodes without them informing the rest of the network.
The spread toolkit may be a bit overkill for what you want, but an interesting starting point.
From the blurb:
Spread is an open source toolkit that provides a high performance messaging service that is resilient to faults across local and wide area networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast, group communication, and point to point support. Spread services range from reliable messaging to fully ordered messages with delivery guarantees.
Spread can be used in many distributed applications that require high reliability, high performance, and robust communication among various subsets of members. The toolkit is designed to encapsulate the challenging aspects of asynchronous networks and enable the construction of reliable and scalable distributed applications.
Spread consists of a library that user applications are linked with, a binary daemon which runs on each computer that is part of the processor group, and various utility and demonstration programs.
Some of the services and benefits provided by Spread:
Reliable and scalable messaging and group communication.
A very powerful but simple API simplifies the construction of distributed architectures.
Easy to use, deploy and maintain.
Highly scalable from one local area network to complex wide area networks.
Supports thousands of groups with different sets of members.
Enables message reliability in the presence of machine failures, process crashes and recoveries, and network partitions and merges.
Provides a range of reliability, ordering and stability guarantees for messages.
Emphasis on robustness and high performance.
Completely distributed algorithms with no central point of failure.
Apples iChat is an example of the very product you are envisioning. It uses Bonjour (apple's zero-conf networking protocol) to identify peers on a LAN. You can then chat or audio/video chat with them.
I'm not entirely sure how Bonjour works inside, but I know it uses multicast. Clients "register" services on the LAN, and the Bonjour protocol allows for each host to pull up a directory of hosts for a given service (all without central management).