Another issue I'm facing :

I need my module to be able to detect changes in the database and report it to the connected users if necessary. (Use case : the person adds a friend with something else than a XMPP client, like a web page interface or a webservice API, while she's connected).

The way I choose to do that is :
- the session manager looks for a syncro='out_of_sync' field in the database
- set syncro to 'syncing' for some rows
- then change the memory roster items and push packets to the user's sessions with selected changes
- then set syncro to 'ok'.
(In order to make this case simpler, I will do as if there were no row deletions, but there are ^_^)

I'm wondering when is the best way to call this function :
- I can make a per-user function, looking only for changes in rows concerning a specific user, and call it at the beginning of the mod->in_sess and mod->pkt_user functions. - I can call it on a regular interval (something like 5 seconds) and look for changes for any user. Then, if the user is loaded, apply changes, and if the user has at least one opened session, send the packets.

For now, I've implemented the first solution. But my feeling is that the 2nd solution would be better performance-wise (too many requests with the 1st). I'm only stopped by the "regular interval" thing.

My question : *Should I add a "timetick" chain to the SM (called every second for example), and add my module to this chain (with a rate_t check) ?* I'm not thrilled by this solution, because for now, I haven't changed any code from jabberd2 except from the new module, which make it easier to test or get in production. *Is there another, better way ?*

Thanks for reading, and I'm grateful in advance for any useful insight. :)

On a side note : the 5s interval could lead to some race conditions, but I think we can avoid any inconststencies (by using "INSERT ... ON DUPLICATE KEY UPDATE ..." instead of "UPDATE ..." for one). The behavior being undetermined if a user issues 2 conflicting commands at the same time through differents means is not an issue, if the resulting state is the result of one of the user's commands.

--
Sylvain "Gugli" Guglielmi
Gamedev@Nadeo@Ubisoft

Reply via email to