How to model/keep per-client data in a crossroads (with or w/o tokio) server

[acatangiu]

Hi all,

I'm trying to create a service that exposes some operations as methods on a particular path, but the server/service also needs to keep per-connection/per-client state between method calls.

Background

For more background, I'm trying to model the kernel interface proposed here: https://lkml.org/lkml/2021/3/8/677 as a user-space DBus interface.

Current tentative interface model:

Have a DBus service com.TBD.sysgenid that exposes methods and signals for consuming and interacting with sysgenid subsystem.

Methods:

• GetGenCounter - no input params - returns latest generation counter
• AckGenCounter - input: client view of the counter - returns ok if client ack counter is correct, err otherwise
  • on top of that, server should also internally track how many clients have ACKed and how many have not - this is where per-connection/per-client data is needed
• SetWatcherTracking - each client is a watcher, sets whether client should be tracked for ACKs or not
• TriggerGenUpdate - triggers generation update

Signals:

• NewGeneration - gen id change notification - contains new gen counter
• SystemReady - all tracked watchers have ACKed new gen counter

Question

How can I keep per client connection data in a crossroads service? Associated data needs to have same lifetime as client connection.

[acatangiu]

As an ugly hack I can use the Sender field from Context::message() of each method call and map that internally to per-client data, but that solves just part of the problem. The service still doesn't have visibility in the connection's (proxy object on client-side) lifetime. No way to track when a new watcher has opened or when it closed connection.

[diwic]

First, I'm assuming you're trying to expose a service on the System (or Session) bus, and not trying to write your own bus.

A D-Bus service usually do not track peers appearing or disappearing on the bus, but if you need to, you should subscribe to the org.freedesktop.DBus.NameOwnerChanged signal. The :1.xxx names are peers' unique name (and usually not reused, not sure what happens on integer overflow). Remember that most peers are on the bus for other reasons than to communicate with your particular service, so no need to store data for them.

And yes, you should check the Sender field of the message to see who sent it; that's the proper way, not a hack.

As for storage, you could either store a HashMap<String, ClientData> on the path for usage in method closures, and use Crossroads::data_mut in your NameOwnerChanged signal handler, or you could have an Arc<Mutex<HashMap<String, ClientData>>> and send one Arc clone into the method handler of AckGenCounter, one clone to SetWatcherTracking (for adding new clients) and one clone in your NameOwnerChanged signal handler.

[acatangiu]

Thanks @diwic, your suggestion worked perfectly!

Ultimately, I had to go for Arc<Mutex<CustomData>>, because I couldn't find a way to access Crossroads::data_mut in my NameOwnerChanged signal handler.