Comments (2)
Hi.
The framework is most definitely designed for long-lived connections. In fact, that is what we use at Fitbit for all our connected watches and trackers, which stay connected to the user's phone 24/7 (when in range of course). Millions of devices are connected that way right now.
The ability to seamlessly get disconnected and automatically reconnected is something we ensure works as well as possible, and there's some support included to allow the detection of bad conditions where, for instance, the BLE channel may become unresponsive (many bugs on mobile phones in different phone models and OS versions...), and recover from it (for example, a callback when the low level link is stalled, which allows the application to take action, like maybe ask for a disconnection and wait for a reconnection, which has the chance to bring things back to a clean state).
Regarding CoAP observe, this is something we have experimented with, but so far decided not to use, because there are some downsides to it, mostly because it is onerous for a small CoAP server to keep track of subscribers that may disappear at any time. We have found more efficient ways of achieving equivalent outcomes, using patterns like the CoAP event emitter class that's included in the framework. This may also be something that would work for your use case.
from golden-gate.
The framework is most definitely designed for long-lived connections. In fact, that is what we use at Fitbit for all our connected watches and trackers, which stay connected to the user's phone 24/7 (when in range of course). Millions of devices are connected that way right now.
That's really interesting, thanks for sharing.
The ability to seamlessly get disconnected and automatically reconnected is something we ensure works as well as possible, and there's some support included to allow the detection of bad conditions where, for instance, the BLE channel may become unresponsive (many bugs on mobile phones in different phone models and OS versions...), and recover from it (for example, a callback when the low level link is stalled, which allows the application to take action, like maybe ask for a disconnection and wait for a reconnection, which has the chance to bring things back to a clean state).
Ok, this means that there is somehow a coupling between layers right? I mean, a signal in the lower layer should be somehow forwarded to the upper layers in order to take a decision. This doesn't broke the idea behind the decision of using GG_Data{Sink,Source}
abstraction in order to keep layers decoupled?
Regarding CoAP observe, this is something we have experimented with, but so far decided not to use, because there are some downsides to it, mostly because it is onerous for a small CoAP server to keep track of subscribers that may disappear at any time.
Yep, we have had the same concerns and we decided to limit the observable paths/sessions/... to an achievable (in terms of codesize&ram) and finite number of them.
We have found more efficient ways of achieving equivalent outcomes, using patterns like the CoAP event emitter class that's included in the framework. This may also be something that would work for your use case.
Umm interesting, thanks for the pointer. As far as I can see in the code it seems like the IoT device is behaving as server & client at the same time, right? CoAP server for requests started in the cloud/mobile and CoAP client for requests (events in this case) started in the IoT devices, those two converged into the same DTLS pipe?
I wanted to share with you a diagram of a different communication lines we currently have to better illustrate our use cases:
(2) This is fairly typical scenario where you use the BLE (as it is ubiquitous) based connectivity for initialization (and sometimes for maintenance tasks). These kind of connections are usually a one-shot tasks. This means that the DTLS handshake happens every time the mobile device wants to connect against the device and it is not kept anywhere as we consider it ephemeral.
(1) Once the connection with the cloud is established, any other application wise communication happens through Hubs/Gateways. Here we keep the DTLS session alive and is distributed between all our servers as it was explained in the pion's issue I mentioned before.
The main difference between the two scenarios is in the layers we plan to use in them. In the (1)'s scenario we should use all the layers (CoAP, DTLS, IP, Gattlink) including the Gattlink as it's based on BLE and we want to achieve the reliability that layer offers. OTOH, in the (2)'s scenario we're probably going to use CoAP + DTLS and IP layers. Take into account that from the cloud perspective, the Hub or whichever devices in the middle doesn't exist. Those devices in the middle are like routing devices that would work at the layer 3 and route everything to our devices.
Our idea was to use this framework because all you explain in the doc. aligns perfectly with what we thought our framework should have. In fact, a lot of the decisions you took in the framework were exactly the ones we reach ourselves without even knowing about golden gate. That being said, I would love to see this framework being used in all of our devices as I think it could be a big win for everyone ;)
Sorry because my issue got larger than I expected but I thought it was appropriate to establish the basis.
I really appreciate your effort on sharing this information with me as it helps us rethinking design decisions again.
from golden-gate.
Related Issues (16)
- Golden Gate & Project Connected Home over IP HOT 4
- Zephyr and WebAssembly roadmap HOT 5
- What is the expected code size for a full featured GG Stack? HOT 2
- Permissioning of NSBluetoothAlwaysUsageDescription for Stack Tool HOT 3
- Support for HTTP/TLS/TCP HOT 4
- Golden gate socket and MTU questions HOT 2
- Windows and Android Studio - issue with libgg.so and libxp.so HOT 4
- Is it possible to increase the speed and throughput? HOT 2
- CoAP/DTLS and X.509? HOT 1
- Exception when using example Android App HOT 8
- Zephyr RTOS - Documentation HOT 2
- Th
- Cortex-M4 Code Migrating HOT 2
- Problem building the project - CMAKE HOT 2
- Program to sync Fitbit device on Windows PC
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from golden-gate.