Future network topology (for discussion)

[John]

@axillent I do get the point, but I'm having some difficulties with the drawing

The controller seems now also acting as a gateway between the home access router and the internet, introducing an extra router like device and immediate access from outside the home/business network.

I would say swap the home router and smart home texts and draw the arrow from the mobile phone to the newly located smart home text.

If the cloud@node is able to access the internet it should have a bidirectional arrow to the home router. It now seems it is able to access the internet just like the mobile without the need of a local access point. To make it more clear of the cloud@node's functionality to be able to access the internet keep the current arrow, and give the internet access arrow a different color, example green. Point the green arrow to the home router and from home router to internet icon.

[hek]

Encryption is handled by the cloud@node right?
Is the idea that gate@nodes post (or keep an data interchange connection open) to both "Smart Home" and cloud?

[axillent]

@John thanks to be so critical in small details))
My picture has no goal to replicate home ethernet network
The goal is only to show links between important components used directly or indirectly by MySensors
But any way, the new picture should reduce number of questions

[axillent]

@hek said:

Encryption is handled by the cloud@node right?
Is the idea that gate@nodes post (or keep an data interchange connection open) to both "Smart Home" and cloud?

in my idea the cloud@node is the node able to listen/sniff for the IP packets coming from sens@nodes to Controll Center. The cloud@node can be configured to filter needed devices and child_nodes and post this data to MySensors@Cloud for the storage, analysis and sharing
I do not assume that anyone else on the network need to take care about cloud@node job

[John]

@axillent Small details can often answer big questions ;)

Does this also mean that controllers would be able to interact with the cloud@node to be able to pass data eligible for remote storage to this instance?

How do you want to listen/sniff packets, broadcast, unicast, multicast? Or is the idea to have dedicated tcp connections to the gates?

[axillent]

@John All is for discussion
I think it will be much more flexible if cloud@node will be working in passive mode, sniffing unicast communication.
Etc. in my scenario sensor@node sends data (temperature for example) through the gate@node to Control Center
This data contains ID of the sensor@node and also child_ID of the particular sensor parameter.

cloud@node will sniffer all unicast packets to Control Center and will filter out IDs not matching it's configuration
Any matching packets will be post to MySensors@Cloud

For me it could be sufficient for the cloud@node to hear all sens@nodes.
Do you see any scenario for the Control Center to post data to cloud@node?

[John]

@axillent
All clear!

I see a lot of opportunities in having a controller post sensor data to the could@node, unless you want to restrict it only to mysensors (which those segments do not imply by the way).

Cheers.

[axillent]

@John OK
but can you provide an example?

the goal of the cloud@node is to collect data from very simple sensor@nodes and pass this data to MySensor@Cloud
he also contain a configuration about what to collect, when and how often

if Control Center needs to record data on MySensors@Cloud it can post data directly to MySensors@Cloud
What could be the additional value of the cloud@node in this need?

[John]

@axillent

The latter would then be the obvious choice, wasn't thinking of that... (discard my last question)

[Swati Sharma]

Network topology is the bargain of the assorted rudiments (links, nodes) of a computer network. Fundamentally, it is the topological arrangement of a complex & may represent actually or reasonably.

link text