LAN protocol message delivery

I am occasionally sending messages at faster rate than recommended rate 20 messages per second. It is possible that some messages get lost or are not processed by light (LIFX Z) as there may be just too much data. Once I receive ack reply for a message can I assume that message will be processed and light will change to desired color? Or is it possible that due to high data rate some messages will not be processed even if ack is sent? For example if I change same zone multiple times in a row, will the latest change always be applied eventually?

Yes you should get only ack replies for messages that get processed.
But UDP makes no guarantee about ordering of messages, if you change the same zone multiple times in a row and the light receives the messages in a different order, the message last received will be applied (and acked) last.
Also if you are sending excessive amounts of messages to a device and ask for ack responses, be aware that asking for ack puts more strain on the resources.

HTH
Florian

Thanks for quick reply @florian. Forgot that in theory it is possible for UDP messages to be delivered out of order. However, that is a risk I am willing to take, yet to see that happen in my setup.

Interesting comment about ack messages adding more strain to resources. From earlier discussions I understood that sending ack would be less demanding than asking for a reply via state message. This is because there is one chip handling networking (including ack?) and another chip controlling lights (include querying light state?) Is my assumption correct?

So my options are to submit updates faster without knowing if they are ever received/applied or to submit them slower and to be certain they are applied (unless UDP packets arrive in wrong order). With latter option I can resend any lost updates. Next step would be to benchmark those two options for update performance and packet loss.

Ideal option would be if LAN protocol had a new message setting multiple zones each with different colour :wink:

@superg asking for ack is definitely better than asking for responses (which in the case of SetColorZones will not contain meaningful data anyway btw), as messages are smaller and require less computation.
Resourcewise the buffer space in the networking stack and in the firmware is quite limited, so messages might get dropped simply to avoid running out of space when receiving too many messages.

@florian Based on my testing LIFX Z led zones can be updated reliably around 100-190 times per second with zero packet loss. In this setup I am not asking for any ack or responses. Performance fluctuation is probably caused by network and depends on time of day, so having a dedicated wireless router for lights could performance further. Does LIFX Z have any hard coded performance limits, official 20 messages per second recommendation is way too low? I know I am pushing the envelope here but so far LIFX Z is greatly exceeding my expectations :grinning:

20 messages is a conservative value, the real-world performance will depend on the type, configuration and size of the messages sent and of course the targeted hardware model.
So your mileage will vary…