8 bits for sequence number too little?

I am just wondering if anyone has stumbled into the limitation of the 8 bits reserved for the sequence field in the Message headers?

It limits the number of sequence-numbers to 256, which might be a little bit short in some cases (in combination with the (same) source field).

Any strategies on how to overcome that, or use that?

I currently track messages sent to bulbs (each bulb has unique source field), and when the bitfield rolls over, it is a marker to flag the bulb as not working, offline, or whatever. (I do not currently have an active polling mechanism in place, not sure if that would be a wise thing to do on the network)

Any thoughts?


Ultimately the sequence number doesn’t have to increase monotonically it is just a tool so that your application can match particular requests to their replies/acknowledgments. Using the sequence number to track these helps improve the simplicity of your retransmission logic. Using it this way means you only need to worry about sequence numbers for which you are waiting for replies. So you can essentially have up to 256 packets waiting for replies at any one time. This should be enough for most applications.

In the SDK I wrote I wanted to handle really large numbers of the bulbs. One of the tricks I did to achieve this is to have separate sequence number iterators per device, and for broadcasts. Because the protocol includes the source you can combine the sequence number and the target address as a packet identifier. This way you can handle 256 outstanding packets per device. :smiley: If you can read Python you might be interested in reading my work on python-lifx-sdk.

Tx for the additional input

I already had it implemented a counter-per-bulb, but still. Cfr the other remark on detecting the actual state of a device, I suppose then that there only one approach and that is to implement a polling mechanism that uses for example Echo messages?


Well there are a few different strategies for device detection. The one I chose for my SDK is to keep track of the time that we saw the last packet from the device. If we haven’t seen a packet for a certain length of time assume that it has gone missing. Then I have a thread that looks for devices that haven’t been seen in a while and polls them.

You can do this with EchoRequest packets or any other packet that returns a response really.