Proposal: Subscribe device message
pdf opened this issue · comments
One of the major problems for clients implementing the current LAN protocol is that keeping local state for devices up to date in an environment where multiple clients may make changes is rather sloppy. The only way to do so currently is to poll all devices on some interval, which can be quite expensive, and adds significant delays to state detection.
I'd propose a Subscribe/Unsubscribe message that takes no additional data, and causes the device to send unsolicited State* messages upon completion of any state change to the origin of the Subscribe message.
To support this feature there should also probably be Ping/Pong keep-alive messages, so that devices can time out subscribers that are no longer available. This controls unbounded growth in case subscribers are transient or change address frequently. With this in mind, perhaps the Subscribe message would take a timeout interval for the health check, however I think it would be quite acceptable to simply have a fixed (and quite protracted) check interval. Perhaps 2 failed consecutive checks would invalidate a subscription.
Implementing this proposal would have some overhead - the device would need to store a small amount of data - the IP/port/identifier and failure count (and possibly interval) for each subscription (probably this needs to be bounded, and subscribe should return error on OOM), and to run a scheduler for keep-alives. There would also obviously be n-1 additional datagrams per state change, where n is the number of subscribers (no need to notify the originator of the state update, since they can just request ACK). I don't know what sort of hardware we're dealing with, but I suspect this wouldn't be too onerous a burden.
The overhead for packet processing/transmission probably actually reduces as clients implement this feature (depending on the health probe interval, though those packets will be considerably smaller than full state updates), as it removes the need for constant state probes against all devices, as state updates are only transmitted by devices when a change occurs.
This doesn't solve detection of new devices appearing on the network (or devices being powered on/off at the wall). The former can probably be solved by a broadcast upon joining the network, the latter not so much - open to ideas, though a long poll by the client is probably not the worst thing here.
/brain-dump
This doesn't solve detection of new devices appearing on the network (or devices being powered on/off at the wall). The former can probably be solved by a broadcast upon joining the network, the latter not so much - open to ideas, though a long poll by the client is probably not the worst thing here.
Thinking about this a little more, with a configurable keep-alive interval, clients can actually just choose to use a lack of incoming pings to detect a powered off device.
Was just asking about this. If there could be some device "power-on" event trigger broadcast so a listening controller could use it as a timer to turn off the bulb.