I'm trying to implementing tree topology with Cooja/contiky. Finding through examples i've not been able to find an a good example to find what i need.
In short :
I'd need to implementing a topology of this type(picture here under) with cooja end contiky, is there someone that could give me some advice?
Thanks in advance
I don't really use Contiki Operating System, I have only ever used TinyOS but a network topology such as the one you have should be easily achievable.
For TinyOS, the mote-to-mote radio tutorial HERE will show you how to two different sensor nodes can communicate with each other (a gateway is basically just a sensor node connected to a PC) and the mote-to-PC communication tutorial HERE will show you how a gateway node can forward information from itself to the PC it is connected to. When the network is running you basically have a Java application listening to USB port and receiving packets from gateway node. Once the packet has been received on the Java application then you can send it to an external network server.
It may sound difficult if you have never developed on TinyOS but what you want to do is very common and so there will be complete programs in the tutorial section of a typical TinyOS distribution showing you how to achieve most of the things you need you need to achieve. There should also be similar examples in Contiki.
Related
I am writing an app that is suppose to work without a connection to mobile carrier and without local WiFi. Each device will act as transmitter, receiver and router.
My main challenge so far is that I cannot figure out how exactly MultipeerConnectivity works as documentation on MC is really limited. Apple denied revealing technical specification of MC claiming it's a proprietary network stack, so I have to rely on network sniffers and reverse-engineering which is not the quickest way to figure out how MC works.
Suppose I have 100 devices forming a mesh network in such way that each device is within the range of at least one other device and at maximum three other devices.
Is there any way to send a message from node A to node B that is not within the range of node A without the need to broadcast the message to all other nodes? I mean that message should be properly routed through all other nodes.
Does MC include a routing layer too or I have to write it myself?
From what I can see ad hoc delay tolerant wireless networks is still a hot subject in research.
These slides on ad hoc delay tolerant wireless network shed more light on the subject as it was a few years ago. And also this paper. Has Apple progressed it much with MC?
I cannot really see any way to send a message between nodes not directly connected to each other without flooding.
Correct?
The MCSession Reference states that
Sessions currently support up to 8 peers, including the local peer.
Also, the overview you cited says
In the discovery phase, your app uses a browser object […] to browse for nearby peers[.]
Moreover, the documentation on managing peers manually suggests that all peers in a session must be connected with each other to have them in a session.
This is suggesting that the framework only covers the communication between nearby devices, as in 'reachable by bluetooth or WiFi'. Naturally, those devices do not need complex routing, as they do communicate with each other and the benefit of the framework is simple multicasting between nearby devices, from a programmers' point of view.
As far as your question goes, this is about it - trivially, since all peers an a MCSession have links to each other - there is no routing needed.
This does however, allow you to construct a routing layer pretty easy.
Given your scenario, there will be multiple MCSessions with devices being part of at least one. All devices that are part of more than one MCSession do become routers and interconnect the MCSessions with each other.
The rest of the task should be straight forward; defining a namespace for addressing devices and implementing a routing protocol of your choice.
The old days of the internet, with unstable dialup connections, might be a plus factor for you as the routing protocols in place are rather stable in regards of link loss.
Here are two good starting points for you to make your choice of better fit:
Link state routing
Distance vector routing
I'm searching for 4 days, but can't get it. I built all libraries and integrated it in my custom project, but I don't know what steps should I do to make it work. The only thing that i found with code example\explanation is tech.appear.in/2015/05/25/Getting-started-with-WebRTC-on-iOS , but it is poor and unclear for me, AppRTCDemo source code too. I read about WebRTC for browsers but still can't reproduce it on iOS.
Can anybody explain or provide links to explanation on how to completely build iOS native app using WebRTC API for example p2p ios chat?
Besides the fact that I do not understand code logic provided in demo, I can't understand:
1) What is ICE servers for my iOS app? Should I take care of it? Is it something server side? Should I code and run it myself, or I can use existing Parse background?
2) What is signaling mechanism in iOS app? Is it client side only, or it must be implemented on server side too?
3) And maybe someone can explain step-by-step guide, maybe with some code, how to implement simple iOS p2p chat using WebRTC? For example:
"You have to:
Create ICE/STUN/TURN server on parse core using this =source= and this tutorial =tutorial=.
Create RTCPeerConnection using created ICEServer:
RTCPeerConnectionFactory *pcFactory = [[RTCPeerConnectionFactory alloc] init];
RTCPeerConnection *peerConnection = [pcFactory peerConnectionWithICEServers:kICEServerURL constraints:nil delegate:self];
Create DataChannel using ...
Send signal using ... explained here =link=
Set local and remote descriptions ...
Send Data ... using ...
... " or something similar.
I'm sorry for asking this, but I'm losing my mind trying to figure it out. Thank you!
I am not an expert in webrtc but i will try to explain some of your questions.
1.ICE servers-- NATs and firewalls impose significant problem in setting up IP endpoints. so IETF standards STUN, TURN and ICE were developed to address the NAT traversal problem.
STUN helps connect IP end-points:
discover whether they are behind a NAT/firewall, and if so,
to determine the public IP address and type of the firewall. STUN then uses this information to assist in establishing peer-to-peer IP connectivity.
TURN, which stands for Traversal Using Relay NAT, provides a fallback NAT traversal technique using a media relay server to facilitate media transport between end-points.
ICE is a framework that leverages both STUN and TURN to provide reliable IP set-up and media transport, through a SIP offer/answer model for end-points to exchange multiple candidate IP addresses and ports (such as private addresses and TURN server addresses).
2.Signaling is the process of coordinating communication. This signalling part needs to be implemented by you according to your needs(for ex. if you have sip structure in place then you will have to implement sip signalling). In order for a WebRTC application to set up a 'call', its clients need to exchange information:
Session control messages used to open or close communication.
Error messages.
Media metadata such as codecs and codec settings, bandwidth and media types.
Key data, used to establish secure connections.
Network data, such as a host's IP address and port as seen by the outside world.
Steps
for offerer:
first create the peer connection and pass the ice candidates into it
as parameters.
set event handlers for three events:
onicecandidate-- onicecandidate returns locally generated ICE candidates so you can pass them over other peer(s) i.e. list of ice candidates that are returned by STUN/TURN servers; these ice candidates contains your public ipv4/ipv6 addresses as well as UDP random addresses
onaddstream--onaddstream returns remote stream (microphone and camera of your friend!).
addStream` attaches your local microphone and camera for other peer.
Now create SDP offer by calling setLocalDescription function and set remote SDP by calling setRemoteDescription.
For Answerer:
setRemoteDescription
createAnswer
setLocalDescription
oniceCandidate--On getting locally generated ICE
addiceCandidate--On getting ICE sent by other peer
onaddstream--for remote stream to add
I hope this will make some of your doubts clear.
I came through the process of implementing it few month ago. What I've found was the library was not stable - sometimes it was working sometimes not.
Additionally my iPhone was always becoming hot when I was using it.
I would not suggest using this library and overall WebRTC technology for commercial projects.
This is my implementation, which was working few months ago:
https://github.com/aolszak/WebRTC-iOS
Good luck!
Just asking one silly question, hope someone can answer this.
I'm bit confused regarding MQTT broker. Basically, the confusion is, there are so many things being used for data storing, transfer and processing (like Flume, HDInsight, Spark etc). So, when and why I need to use one MQTT broker?
If I would like to use Windows 10 IoT application with HiveMQ, from where can I get the details? how to use it? How I get benefit out of this MQTT broker? Can I not send data from my IoT application directly using Azure or HDFS? So, how MQTT broker fits into it or helping me to achieve something?
I'm new to all these and tried to find some tutorials, however, I'm not getting anything proper. Please explain it in more details or give some tutorials for this?
MQTT is a client-server protocol for pub-sub based transport that has a comparatively small overhead, and thus applicable to mobile and IoT applications (unlike Flume, etc.). The MQTT broker is basically a server that handles messaging to/from MQTT clients and among them. The functionality pretty much stops at the transport layer, even though various MQTT add-ons exist.
If you are looking to implement a solution that would reliably transfer data from your IoT devices to the back-end system for processing, I would suggest you take a look into Kaa open-source IoT platform. It goes much further than MQTT by providing not only the transport layer, suitable for low-power IoT devices, but also a solid chunk of the application level logic (including the object bindings for your application-level data structures, temporary data persistence, etc.).
Here is a link to a webinar that explains how to build a scalable IoT analytics system with Kaa and Spark in less than an hour.
This is an architectural choice. IoT applications are possible without MQTT but there are some advantages when using MQTT. If you are completely new to MQTT, take a look at this in-depth MQTT series: http://forkbomb-blog.de/2015/all-you-need-to-know-about-mqtt
Basically the main architectural advantage is publish / subscribe designed for low-latency, high throughput (mobile) communication with minimal protocol overhead (which is important if bandwidth is at a premium). You can completely decouple consumers and producers.
HDFS is the (distributed) Hadoop file system and is the foundation for Map / Reduce processing. It is not comparable to a MQTT broker. The MQTT broker could write to the HDFS, though (in case of HiveMQ with a custom plugin).
Basically MQTT is a protocol while the products you are mentioning are, well, products which solve completely different problems:
Flume is basically used for log aggregation at scale. You won't use MQTT for that, at least there is not too much advantage because this is typically done in backend applications.
Spark and Hadoop shine at Big Data crunching. They are a framework and not a ready to use solution. They are not really comparable to MQTT. Often MQTT brokers like HiveMQ are used in conjunction with these, Spark / Hadoop for data processing and HiveMQ for communication.
I hope this helps you getting started. Best would be to read about typical use cases of all these technologies, this is a bit too broad for a single SO answer.
MQTT is a data transport, so the usual thing I have to compare it with is HTTP. HTTP has two important characteristics, a) It goes from one point to another, b) It is request/response, so only one end can start a data transfer. MQTT connects many end points to many end points, and either end can start a data transfer. So, if you have just one device and only one service or person that will ever access it, and only by polling, then HTTP is great. MQTT means many devices can post data to many services or people, AND the other way around. Your question assumes that your data is always going to land up in some sort of data store, but many interactions are about events and responding to them immediately, like ringing a doorbell, or lowering the landing gear. In these cases you will often want to both record the data, and have an immediate action occur, like your phone making a doorbell noise.
Finally, you send data to MQTT semantically, rather than by IP address.
This means that your services subscribes to /mikeshouse/doorbell rather than polling 192.168.22.4, which is a huge gain once you have a number of devices.
I am trying to connect ICP CON i-7565 (USB<->CAN interface) to a custom made device (supporting CAN2.0B, proved to work with PCL-841 card) Although I think I have configured BAUD and acceptance code/mask correctly I can see CAN no messages coming from the device (ICP provides a tool that should allow me to send and receive CAN messages).
I am new to CAN bus so I appreciate any help regarding how to identify the problem.
I-7565 might be wrong interface for me, I might have misconfigured it, or it is simply broken. Or I am just doing something wrong out of my ignorance. I don't think anyone can help me with my specific problem, so I am rather asking for general information on how are problems with CAN bus identified and analyzed. In TCP/IP for example, you would call ping, you'd recheck your ip and gateway settings etc. What do you do for CAN communication?
Additional info:
OS: Win7 64bit
connector: DB-9 with standard wiring (2,3,7)
Finally I tried to work with different USB<->CAN interface from different manufacturer and it worked like a charm. My old interface was either broken or incompatible for reasons unknown. While working on this problem I learned couple of things about CAN bus and so now I share what I think was the right answer to my original question: How to troubleshoot CAN bus communication?
read manual to your USB-CAN interface
install driver of your interface device and make sure it is working (check device manager, depending on the type of your device you will see new COM port added or new USB controller )
your device should be shipped with it's own test/analysis software (they might call it utility or similar), run it and check if it can connect to your device
CAN communication uses three wires that are referred to as High, Low and Ground and is usually connected with DB-9 connectors where High is linked to pin n. 7, Low to pin n. 2 and Ground to pin n. 3 or 5 - make sure this is connected correctly on both your USB interface and CAN device you want to communicate with
set properties of your connection, these are most of all: CAN type (2.0A or 2.0B) BAUD rate, Acceptance Code and Acceptance Mask
if you've done all of this and still you can see no CAN messages arriving in your utility program, check with a different USB-CAN interface or find some other way to test if your device is actually emitting CAN messages and your USB interface is in fact able to receive them. (this was actually my case)
I need to use one logical PGM based multicast address in application while enable such application "seamlessly" running across several different geo-locations (i.e. think US/Europe/Australia).
Application is quite throughput (several million biz. messages a day) and latency demanding whith a lot of small but very frequently send messages. Classical Atom pub will not work here due some external limits of latencies.
I have come up with several options to connect those datacenters but can’t find the best one.
Options which I have considered are:
1) Forward multicast messages via VPN’s (can VPN handle such big load).
2) Translate all multicast messages to “wrapper messages” and forward them via AMQP.
3) Write specialized in-house gate which tunnels multicast messages via TCP to other two locations.
4) Any other solution
I would prefer option 1 as it does not need additional code writes from devs. but I’m afraid it will not be reliable connection.
Are there any rules to apply for such connectivity?
What the best network configuration with regard to the geographical configuration is for above constrains.
Just wanted to say hello :)
As for the topic, we have not much experience with multicasting over WAN, however, my feeling is that PGM + WAN + high volume of data would lead to retransmission storms. VPN won't make this problem disappear as all the Australian receivers would, when confronted with missing packets, send NACKS to Europe etc.
PGM specification does allow for tree structure of nodes for message delivery, so in theory you could place a single node on the receiving side that would in its turn re-multicast the data locally. However, I am not sure whether this kind of functionality is available with MS implementation of PGM. Optionally, you can place a Cisco router with PGM support on the receiving side that would handle this for you.
In any case, my preference would be to convert the data to TCP stream, pass it over the WAN and then convert it back to PGM on the other side. Some code has to be written, but no nasty surprises are to be expected.
Martin S.
at CohesiveFT we ran into a very similar problem when we designed our "VPN-Cubed" product for connecting multiple clouds up to servers behind our own firewall, in one VPN. We wanted to be able to run apps that talked to each other using multicast, but for example Amazon EC2 does not support multicast for reasons that should be fairly obvious if you consider the potential for network storms across a whole data center. We also wanted to route traffic across a wide area federation of nodes using the internet.
Without going into too much detail, the solution involved combining tunneling with standard routing protocols like BGP, and open technologies for VPNs. We used RabbitMQ AMQP to deliver messages in a pubsub style without needing physical multicast. This means you can fake multicast over wide area subnets, even across domains and firewalls, provided you are in the VPN-Cubed safe harbour. It works because it is a 'network overlay' as described in technical note here: http://blog.elasticserver.com/2008/12/vpn-cubed-technical-overview.html
I don't intend to actually offer you a specific solution, but I do hope this answer gives you confidence to try some of these approaches.
Cheers, alexis