Broadcast timing

[spinarr]

• there is no need to wait for response when sending to broadcast address (no response is coming)
• there should be wait till the broadcast packet is routed from coordinator to all nodes only (not include time for routing back as in unicast)

{ "ctype": "dpa", "type": "raw", "msgid": "1529411821", "request": "ff.ff.02.01.ff.ff", "request_ts": "2018-06-19T12:37:01.595902", "confirmation": "ff.ff.02.01.ff.ff.ff.00.3b.08.00", "confirmation_ts": "2018-06-19T12:37:01.645189", "response": "", "response_ts": "", "status": "ERROR_TIMEOUT" }

[hanakv]

DPA ingores higher byte of NADR. In case of a request with NADR FF.XX. (where XX is non-zero higher byte), DPA consider broadcast request, daemon unicast. The solution is to ignore higher byte of NADR at daemon too. Agree?

[fmikulu]

I don't understand. I thing the solution is to identify broadcast and not to wait for DpaResponse, just terminating transaction with OK

[spinarr]

There should be waiting for forward routing to happen. You can not flood the network with many broadcasts that will not work. Another broadcast to the network can be sent once previous has been routed to whole network.

[hanakv]

This work if NADR is 255 (FF.00). Request "ff.ff.02.01.ff.ff" is not identified as broadcast (kBroadCastAddress = 0xff) To identify broadcast we have to ignore NADR higher byte if ( (receivedMessage.NodeAddress() & 0xff) == DpaMessage::kBroadCastAddress ) OK?

[fmikulu]

I didn't study broadcasting mechanism and I am afraid it wasn't implemented in clibdpa1 neither clibdpa2. To @hanakv if you now how to do it, go ahead. My only concern is just to identify broadcast is not enough. I guess there would be some special handling in transaction timing.

[spinarr]

Done as suggested by @hanakv.