<div dir="ltr"><div dir="ltr">Brett,<div><br></div><div>Yes, exactly.  Most of the components I'm familiar with are supposed to live in the same rack with direct cabling between them for this kind of thing.  People often separate them to some degree with various levels of success, depending mostly upon the stability of the network between them.</div><div><br></div><div>In this case having the option would certainly be nice, and I would happily accept the caveats.</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 12:31 PM Brett Nemeroff <<a href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Jeff, I think a lot of the problem is the active chit-chat in the updates. It’s a lot. I can see however your use case makes a lot of sense and for a redundant pair sitting next to each other, I think it *could* make sense, if it is fast enough. </div><div dir="auto"><br></div><div dir="auto">I’m curious if Razvan would consider making it an option that can be turned on with the understanding that it doesn’t work well across DC boundaries because of the timing and need to happen quickly for synchronization. There are plenty of infrastructure components with this guideline for similar reasons. </div><div dir="auto"><br></div><div dir="auto"><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 10:48 AM Jeff Pyle <<a href="mailto:jeff@ugnd.org" target="_blank">jeff@ugnd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Alexei,</div><div><br></div><div>I see the article.  In summary, transactions are too complicated to synchronize between nodes of a cluster because of their short timing intervals and complex structures.  Instead the approach is to get the messages of a transaction back to the individual node that owns the transaction so it can process there.  Got it.</div><div><br></div><div>For a cluster with many anycast nodes, this makes a lot of sense.  For a simple active/standby setup, it prevents one from achieving a hitless failover from one node to another if there are active transactions.  Bummer.  I'm sure Razvan and the team understood this when deciding on this architecture.  Big picture their approach solves a lot more problems than it creates, and it's very cool nonetheless.</div></div><div dir="ltr"><div><br></div><div><br></div><div>- Jeff</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 1:56 AM Alexey Vasilyev <<a href="mailto:alexei.vasilyev@gmail.com" target="_blank">alexei.vasilyev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jeff,<br>
<br>
Transactions are not replicated.<br>
Here<br>
<a href="https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/" rel="noreferrer" target="_blank">https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/</a><br>
Razvan explains why. Section "Distributed transactions handling".<br>
<br>
<br>
<br>
-----<br>
---<br>
Alexey Vasilyev<br>
--<br>
Sent from: <a href="http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html" rel="noreferrer" target="_blank">http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html</a><br><br>
</blockquote></div></div></blockquote></div></div><br>
</blockquote></div></div>