Check valid source in client status callback for server status message

RE: Check valid source in client status callback for server status message

Hung Bui — Fri, 29 Mar 2019 11:56:18 GMT

Yes it's a unacknowledge message. But we are checking if the unacknowledge message was from the server that we expected to receive that status or not.

RE: Check valid source in client status callback for server status message

qmorrison — Mon, 25 Mar 2019 20:20:47 GMT

Hi, I'm a little confused here... From the Bluetooth Model Spec:

According to the spec, a Status message is an unacknowledged message, aka NOT a reliable message...

RE: Check valid source in client status callback for server status message

Hung Bui — Thu, 19 Jul 2018 11:25:26 GMT

Hi Armin,

You are right. We will ignore the message if it's not from the publication address of the client. It's only because in our design we don't plan to process status from a group address.

I guess it wouldn't harm to process all packets sent to the subscribed group addresses or the unicast address of the client.

Basically the is_valid_source() can be removed. We will check with the Mesh team to see if it's really needed.

RE: Check valid source in client status callback for server status message

Armin — Wed, 18 Jul 2018 15:16:23 GMT

That's exactly what I do: my client waits for a status broadcast from a server. Both client subscription and server publication are configured to the same group address. Server sends the status using the function generic_on_off_server_status_publish() from the Generic On Off Server Model. This leads to a call of the mentioned function handle_status_cb() in the Generic On Off Client Model.

RE: Check valid source in client status callback for server status message

Hung Bui — Wed, 18 Jul 2018 13:53:36 GMT

Hi Armin,

Sending reliable message to a group address is not recommended by spec.

If an element transmits a message to more than one element, for example it has set the destination address to a group address, the element may not know how many elements may respond to the message. It is not recommended to send an acknowledged message to the all-nodes address. To increase the probability of successful delivery of messages, the sending element should determine how many message retransmissions are required before it considers that all the nodes that should have received the message have actually received it.

Instead the client can wait for a status broadcast from servers. The server can be configured to send automatically after receiving a non-reliable message from the client.