Hello Olle,

I may eventually create a sample config, but there are still a few things missing. However, the htable integration alone has enabled us personally to replicate things like call profiles (for concurrent call limiting), failed authentication attempts, etc. across a cluster of servers without having to define the other node addresses anywhere in the config.

Generally, peers are registered from directly within other modules at startup (see htable for example). Then at the beginning of config you would add something like...

if (method == "KDMQ") { dmq_handle_message(); }

...and the dmq module would pass the message directly to the already registered peer for internal handling.

However, each peer is uniquely identified by the user part of the request URI, so it is equally possible to send an arbitrary message from within config on one server and handle it directly in config of others, like:

(Sending side)

dmq_bcast_message("custom_peer_name", "Some serialized data...", "text/plain");

(Receiving side)

if (method == "KDMQ") { if ($rU == "custom_peer_name") { #do something here } else { #pass it on to be handled by pre-registered peer dmq_handle_message(); } }

The serialization/deserialization of the body content is entirely up to the module developer (in code) or server administrator (in config). It can be anything - or nothing. Currently in the config, we're using it to replicate PUBLISHes, although I plan to integrate dmq into the presence module directly in the very near future. Then there is no need for anything special in the config, just like htable is now - other than setting modparam to enable it of course.

Best regards, Charles

On 25 February 2014 21:03, Olle E. Johansson oej@edvina.net wrote:

...

dmq: added function to broadcast message from config file.

THanks,

This commit caused me to re-read the DMQ docs as I am happy to see that it is starting to move forward again as a module. What I fail to understand at this point is how incoming messages are handled. I see a handler but then - what?

The doc says something about using a library for serialization... Of what?

How can this be used in a normal configuration example? Can event_routes be added to handle incoming messages like normal messages?

I feel there's a diamond hidden in there somewhere, and fail to find it ;-)

/O

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev