You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mbed Client provides an API to add your own entropy source into the underlying SSL library. There is a default entropy source provided by mbed Client. It uses PRNG seeded with RTC for the security but some platforms do not have RTC, and for some, this level of security may not be strong enough.
66
66
67
-
Now, an application can pass its own entropy source to mbed Client as function pointer callback through an API,`set_entropy_callback(entropy_cb callback)`.
67
+
Now, an application can pass its own entropy source to mbed Client as function pointer callback through an API`set_entropy_callback(entropy_cb callback)`.
68
68
69
69
Here is an example on how you can use it from an application:
70
70
@@ -101,7 +101,18 @@ The maximum single UDP message size that mbed Client can receive is 1152 bytes.
101
101
102
102
For transferring larger amounts of data, the Blockwise feature must be deployed. When using this feature, mbed Client can handle messages up to 64KB. This feature is disabled by default.
103
103
104
-
To enable the Blockwise feature, you need to create a `config.json` file in the application level.
104
+
For mbed OS, to enable Blockwise feature , create a `mbed_app.json` file in the application level and overwrite Blockwise value as described below:
For yotta based builds, to enable the Blockwise feature, you need to create a `config.json` file in the application level.
105
116
106
117
*Example:*
107
118
```
@@ -115,9 +126,19 @@ Acceptable values for the `coap_max_blockwise_payload_size` flag are:
115
126
116
127
### CoAP message deduplication
117
128
118
-
Message duplication is disabled by default. More information about deduplication in the [CoAP specification](https://tools.ietf.org/html/rfc7252#page-24).
129
+
By default, message deduplication is disabled. More information about deduplication in the [CoAP specification](https://tools.ietf.org/html/rfc7252#page-24).
130
+
131
+
For mbed OS, to enable message deduplication, create a `mbed_app.json` file in the application level and overwrite the deduplication value as described below:
To enable message deduplication, you need to create a `config.json` file in the application level.
140
+
```
141
+
For yotta based builds, to enable message deduplication, you need to create a `config.json` file in the application level.
121
142
122
143
*Example:*
123
144
```
@@ -127,6 +148,53 @@ To enable message deduplication, you need to create a `config.json` file in the
127
148
```
128
149
Recommended values for the `coap_duplication_max_msgs_count` flag are 0 to 6. Value 0 means that the feature is not used. It is not recommended to use higher value than 6, because it increases the memory consumption.
129
150
151
+
### Reconnectivity
152
+
153
+
Apart from standard CoAP features, mbed Client also handles reconnectivity logic on behalf of applications, thereby aiming to provide seamless connectivity experience and recovery from temporary network hiccups or service side disruptions.
154
+
155
+
The reconnection logic handles the following:
156
+
157
+
- Reconnection towards mDS; establishing the network connection and re-registration to mDS.
158
+
- CoAP message resending logic. More information about resending in [CoAP specification](https://tools.ietf.org/html/rfc7252#section-4.8).
159
+
160
+
There are two parameters in the reconnection logic, both configurable by the application:
161
+
162
+
- Reconnection Retry
163
+
- Reconnection Time Interval (in seconds)
164
+
165
+
mbed Client tries to establish a successful connection to the server by incrementing the reconnection trials every time there is a failed connection attempt.
166
+
167
+
The logic of the `Reconnection Timeout` is `Reconnection Retry count * Reconnection Time Interval` , where `Reconnection Retry count` is incremented by 1 with every failed reconnection attempt.
168
+
169
+
mbed Client continues to attempt a reconnection until `Reconnection Retry count` reaches the defined value (either by the application or the default value set in Client).
170
+
171
+
If mbed Client still cannot establish a connection and the set `Reconnection Retry count` is reached, it returns an error through a callback with an appropriate error code defining the reason for failed connection.
172
+
173
+
There are a few exceptions to the reconnection logic though. If mbed Client sends registration data that is rejected by the server, the client returns an error and does not attempt a reconnection as the server has rejected the data from the client. A typical example of such case would be passing a non-matching endpoint name or domain name against the client certificates.
174
+
175
+
Applications can define their own parameters for the reconnection logic.
176
+
177
+
For mbed OS, to overwrite the reconnection retry count and reconnection time interval, create a `mbed_app.json` file in the application level and overwrite the values as described below:
178
+
179
+
*Example:*
180
+
```
181
+
"target_overrides": {
182
+
"*": {
183
+
"mbed-client.reconnection-count": 3,
184
+
"mbed-client.reconnection-interval": 5,
185
+
}
186
+
187
+
```
188
+
For yotta based builds, to overwrite the reconnection retry count and reconnection time interval, you need to create a `config.json` file in the application level.
189
+
190
+
*Example:*
191
+
```
192
+
{
193
+
"reconnection_count": 3,
194
+
"reconnection_interval": 5
195
+
}
196
+
```
197
+
130
198
## How to use the API
131
199
More information on how to use the API effectively to create and configure Objects, Object Instances and Resources, can be found [here](Howto.md).
By default, callbacks are handled in the `value_updated()` function but the application can also define a callback function for an individual resource.
0 commit comments