Regarding Enumeration callback behavior

[jreveane]

Hi,

 

I've noticed that when a client registers a IPCON_CALLBACK_ENUMERATE callback,

this callback gets fired each time any client connected to the same Brickd requires an enumeration.

I would have expected this to happen only for the context of the client

which has performed an enumeration itself.

Looking at the API, I didn't notice any parameter or call to filter out unexpected enumeration events.

So, is this the expected behavior ?

Thanks.

[borg]

That is indeed expected behavior. The Enumeration Callback is handled as a normal callback. Callbacks don't have an explicit receiver in our protocol, so they are always broadcasted.

 

For Example: If you Configure the temperature callback of the Temperature Bricklet to be called every 10ms, every client that registers the callback will receive the temperature callback (every 10ms).

 

There are several good reasons for that: Most importantly it saves a lot of scarce bandwith. It would also be impossible for the Bricks/Bricklets to handle an arbitrary number of different callback configurations, so we would have to limit the number of possible client connections to the Brick Daemon to something like two or three .

[jreveane]

Thanks a lot for your reply.

However, I  must probably miss the point but I don't  understand where is the bandwidth gain if all the clients get these notification, in particular in the case of clients connected to brickd (running on a Linux system for example) over a TCP/IP connection ? Unless you use UDP multicast ?

Please forgive my ignorance about the internal design and constraints, but I would have expected brickd to main a context per client connection.

This would avoid the need on the client side to filter out unexpected events, which is likely error prone...

Thanks.

[photron]

Brick Daemon maintains a context per client connection for routing responses. But it doesn't try to be clever about callbacks, because if brickd is wrong about its guesses about callback handling then your application can miss a callback because brickd made the wrong decision.

 

For example, how should brickd decide which enumeration callbacks to send to a particular client connection? Should it keep track about when the last enumerate request was received from a client and pass all incoming enumerate-available callbacks to that client for until x milliseconds after the last enumerate request? But then what's the correct value for x? If it's too short you might miss enumerate-available callbacks you should have received. If it's too large you could get callbacks you want to have filtered out. Also, if the time windows for two client connections for the enumerate-available callback passing overlaps then you still get callbacks twice.

 

It's much easier to deal with this in the client application itself. If you see an enumerate callback that tells you that a Brick(let) is connected/available/disconnected and your client application already knows that the Brick(let) is in that state then you can just ignore this event. Yes, this means your client application needs some state tracking for this. But it is much better suited in your client application than in brickd. Because in your app you can do it in a way that fits your needs. In brickd there would have to be one model that has to fit all needs.

 

Also brickd is designed to keep as minimal state information as possible. The less state brickd has to track the less state can be wrong or out-of-sync. This is something we learned from protocol version 1, were brickd had to track more state information. This approach allows you to restart brickd at any time because with the current protocol version 2, there is no essential state information anymore. The minimal state that brickd tracks is optional and just used to optimize the response routing.

[jreveane]

Thanks a lot for your detailed reply. I understand your design decisions, but this behavior is really unusual to me.

If brickd can not filter the callbacks, then the TKF client library should take care of it IMHO, not the client code.

Thanks.