<div dir="ltr">Hello Bob,<div><br></div><div>As previously stated, it is a needed improvement.</div><div><br></div><div>My time is heavily consumed right now, so your patch will be gratefully received.</div><div><br></div><div>My only comment would be that once connected to the cluster, notifications are sent to all nodes anyway, not just the one specified in the notification address parameter. So practically, the only need for resolving multiple records is on start-up to find the first available node. Upon contact with that node, a list of the other nodes is returned, all of which are stored and included in subsequent notifications - this is fairly fault-tolerant, providing your network is well designed. It is not tolerant of network splits etc, where it could be possible to end up with two or more separated clusters or split-brain type situations. However, to overcome that, I think we're looking at a *major* redesign - far more than can be achieved with multiple notification addresses. We'd also likely need to consider quorum, voting a primary/master etc. to do it properly.</div><div><br></div><div>Otherwise, it is a welcome addition in my opinion.</div><div><br></div><div>Cheers,</div><div><br></div><div>Charles</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 March 2015 at 21:41, Robert Boisvert <span dir="ltr"><<a href="mailto:rdboisvert@gmail.com" target="_blank">rdboisvert@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>DMQ Developers,</div><div><br></div><div>Our team would like to setup a <a href="http://kamailio.org/docs/modules/4.2.x/modules/dmq.html#idp2640048" target="_blank">DMQ bus</a> that contains more than one <a href="http://kamailio.org/docs/modules/4.2.x/modules/dmq.html#dmq.p.notification_address" target="_blank">notification address</a> to support a high availability, fault-tolerant system where multiple servers are used to maintain the list of DMQ nodes. The failure of any one DMQ node or the startup order should not cause the DMQ bus to lose track of available nodes. As nodes go offline and online the DMQ bus should be updated using information from the active nodes. To do this we propose changing the way DMQ uses the notification address.</div><div><br></div><div>Currently the notification address resolves a DNS name to a single IP address even if a SRV record or multiple A/AAAA records are available. The proposal is to use all the A/AAAA records or SRV targets returned from a DNS name query as notification addresses.</div><div><br></div><div>Do you have any comments, concerns, suggestions, or recommendations regarding this proposal? Your input is definitely welcome.</div><div><br></div><div>Thank you,</div><div>Bob</div></div>
<br>_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br></blockquote></div><br><div><br></div>
</div></div>
<br>
<font face="Helvetica, Arial, sans-serif"><font size="2"><span style="font-size:10pt"><a href="http://www.sipcentric.com/" title="blocked::http://www.sipcentric.com/" target="_blank">www.sipcentric.com</a><br>
<br>
Follow us on twitter <a href="http://twitter.com/sipcentric" title="blocked::http://twitter.com/sipcentric" target="_blank">@sipcentric</a><br>
<br>
<font color="gray">Sipcentric Ltd.
Company registered in England & Wales no. 7365592.</font> <font color="gray">Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.</font></span></font></font>