I have an ethernet network that is connected like the following.
Only switches and the central computer are depicted. There are more devices connected to the individual switches within the buildings, but it's not what this question is about.
What is the technically correct way to describe this network topology?
I have found the term "tree topology" online, with similar network examples. Can the following network be described as such?
That's a tree. Just picture any of the left-side switches slightly more to the left and you should see it.
The network in your diagram is not a good setup due to chaining. Any of the left-side switches failing takes down more of the network than is necessary.
A better alternative is a central ("core") switch that all the others connect to. Any switch failing only takes down the connected nodes, except for the core switch (which you could make redudant).
Related
I'm looking into how one would create a network of embedded systems. What I'd like to achieve is for a device (basically a chip with network capabilities) to directly send data to a server but not use the internet(tcp/ip) or cellular data(like GSM etc).
I don't have much expertise in this field. Most of the networking protocols I've seen like ZigBee are designed for a Local Area Networks. Wide Area Network can be achieved perhaps over mesh or hoping etc. But is there a known protocol for long range networking, say for sensors, assuming there aren't low power constraints?
I am guessing you want to avoid the internet and GSM, not because you have anything against the protocols but because you want your solution to work without having to rely these networks.
If so then you don't have to rule out TCP/IP as this can be used in private networks also.
From your description it sounds like the closest thing that would meet your needs would be a satellite based communications system. So long as you are not worried about price, power and to a certain extend size, then your sensors can communicate from anywhere using satellite links.
There are also HAP - High Altitude Platforms. These are essentially like low flying Satellites, or high flying planes/blimps, so don't have the same coverage but need less power for a given communication bandwidth. If you search for 'High Altitude Platform Networking' you should find plenty of examples such as the following which is an up to date summary of the technology at the time of writing:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S2175-91462016000300249
As mentioned above, many if not all of these systems will support IP based communication protocols on top of their lower layers. Unless you really have some issue with the protocols themselves, it seems sensible to use them as there is such a wealth of experience, tools etc associated with IP communications, and using them does not make you dependent on the wider 'Internet'.
Its also worth mentioning that a common pattern is to have local groups of sensors communicate with each other and or with a gateway and the gateway then communicate over the long link back to your server. This allows the individual device be smaller, cheaper, lower power etc. This may not match your requirements if you are not likey to have clusters of sensors, however.
If you search for satellite sensor networks you may find you get a lot of hits for the gateway case mentioned above. This article 'A Survey of Architectures and Scenarios in Satellite-Based Wireless Sensor Networks: System Design Aspects' looks to be a good overview which includes HAPs also and it is available to download form this site at the time of writing:
https://www.researchgate.net/publication/250003254_A_Survey_of_Architectures_and_Scenarios_in_Satellite-Based_Wireless_Sensor_Networks_System_Design_Aspects
I would look into LoRa which is designed with these requirements in mind.
You still need infrastructure for that (gateways, network servers), you could roll out your own or (in urbanized areas) use pre-existing one like TTN.
The choice of networking technologies depends on many factors, such as range, power constraints, bandwidth requirements and so on.
User Raber already pointed out that you could look into LoRa / LoRaWAN. Since nobody else mentioned it yet, my suggestion is to also have a look at SigFox technology, which is slightly different from LoRa in what it offers and their business model.
I want to preface this by saying that I've never taken a networking class but I'm learning on the job. Things like TCP/IP networking I have a pretty basic grasp of and if you think this will hinder my attempt at this let me know.
The task I have at hand is thus: I have an Open Stack network with a bunch of nodes that can communicate with each other, all running CentOS virtual machines (just for simplicity's sake) with applications running on top of them. The task is basically to find a way to monitor the ping of every node and report whenever some kind of message (probably through http) that reports what happened. The logic of checking for the actual latency problems isn't what I'm struggling with, its the best structure to complete this task.
I'm thinking of using Nagios and setting up a distributed monitoring system. Basically my plan is to instal nagios on each node after writing my plugin (unless its already offered or exists) and it would simply ping everything else in the network once its setup and the other nodes ping it once the fact that it has joined the network is detected. I'm not sure exactly how scalable this is because if the number of nodes increase a lot would having every node pinging every other node actually be a good thing? Could it actually end up being a lot of stress on the network?
Is this a bad idea? I know a more efficient solution would be something where as long as every node is being checked (not necessarily have to have every node connected to by every other node) is more efficient. Visualizing it as a graph with a couple of points, it would be a bidirectional graph with just one path connecting each point rather than every possible point having edges between each other. But I don't know if this is the level I should be thinking about it or not.
In short, what I'm asking is: How would one go about setting up a ping monitoring system between a bunch of Open Stack nodes?
Let me know if this question makes sense. Thanks.
Still not entirely sure what you're trying to accomplish with this setup, but the Nagios setup you're describing sounds messy and likely won't cover what you need. I'd look at building packetbeat into the provisioning of each of your hosts, and then shipping that data off to Elasticsearch. That way you can watch your actual application-level traffic and response times. https://www.elastic.co/products/beats/packetbeat
I have been playing with Contiki for some time now and have tried out various examples and wrote my own for both the simulation environment and the real hardware. I have only been experimenting with self contained networks that, for example, measure the temperature difference between two nodes and then communicate that data with other devices (PCs) over plain text RS232 link, blink LEDs, and such simple stuff.
Now I want to make a more complicated system where instead of just forwarding the data in plain text to be read on a console I would forward it to an application that would in turn post it to some sort of web service and, vice versa, receive data from web service to be delivered to nodes on the network. There is quite a lot of examples and tutorials describing this kind of setup but all of them (as far as I am aware) are focusing on the IP(v6) stack and SLIP to achieve this. The problem with this is that I have a really lousy programmer and uploading of a 50 kB image takes about 1.5 mins so the development cycle is pure hell. I am also out of luck with simulation since my platform is not really supported at the moment.
That's why I decided to try out the Rime stack, image size is 1/3 of the IPv6 and the development cycle is somewhat acceptable now (I really should get a decent JTAG programmer...) Meanwhile, I am having a bit of trouble wrapping my head around this new setup with a different network stack on which there is very little information around. Although it is pretty easy to understand by itself, I am not sure how I would go about connecting a Rime network to an IP network and if it was even possible or advised/intended by it's designers.
I have some ideas in my head, ranging from ad hoc communication over a serial link between a server application running on the PC and the collector node, to a real Rime border router that is certainly outside of my league, for now.
How would you go about it? It would certainly work for my simple experimental case to just have a collector node that gathers the data from the Rime network and sends the aggregated data over a serial connection to the custom application that does the rest of the magic, but, I wouldn't want to be the guy that reinvented the wheel and I am quite sure that Rime wasn't designed to be used in a vacuum so there must be at least an advised way of doing this?
Rime is a really simple stack (By simple I mean few functionnality). But it's quite quicker for simple task.
You need to program the Rime stack on your gateway. Thus, your board and the gateway can communicate with the same stack. So now you have the data send on your gateway. The gateway now can send the data with IP to whoever you want.
If you want more technical detail, then edit your question with more specific technical context.
Btw JTAG is a must have. (for industrial application)
Edit : An other solution is to simply send your data from your board to your gateway in broadcast. Then the gateway take the data and interpret it. The cons of this method is you have to somehow be sure that your gateway interpret only the data of your board (not of others board)
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.
First-timer on Stack Overflow here. I'm surprised nobody seems to have asked this question, and I hope this is the right place to ask this. I'm trying to determine if I should expect regular network switches (just simple switches, not routers) to have the capability to isolate local network traffic (i.e. targeted traffic that is directed to another local port in the ame switch) within the switch?
For example, if I have 2 machines connected to ports on the same switch (say, ports 2 and 3) and conversing using a directed, non-broadcast protocol (e.g. TCP), I wanted to make sure the traffic between these 2 machines are not forwarded the the rest of the network outside of the switched subnet.
I'm building a home network and I wanted to build private network "subnets" or "zones" using switches where local subnet traffic does not get forwarded to the "backbone" or the rest of the network. Note that I am NOT trying to block any inbound or outbound traffic to/from/between these "zones", but I just wanted to implement a "need to know" basis for these zones to limit network-wide exposure for localized traffic destined within the same switch. Specifically, I wanted the backbone to have as little unnecessary traffic as possible.
So back to the original question: is it fair to expect any network switch out there to be smart enough not to forward local traffic to the rest of the network? I would expect this to be the case, but I wanted to make sure.
PS: You can assume I have a DHCP/WINS server somewhere on the network that will be assigning IP addresses and the such.
I hope the question makes sense, and any help will be appreciated!
- K.
Short answer: yes, the switch is smart enough (otherwise it would be a hub).
And if you need fancy stuff you might have a look a VLANs.
And I believe this question belongs to serverfault or maybe superuser. That's probably why nobody asked it here :)