<div dir="ltr">Thanks!  Is there a release date for 3.3.0?  I hope it is also in 3.3.0. :-)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 9:48 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 27/01/2014 16:36, Dann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How hard would it be to implement an option for federation that would<br>
use the x-received-from header to know if a message came from an<br>
upstream and then not send it back that way?<br>
</blockquote>
<br></div>
It's on the TODO list. It *might* be in 3.3.0. (I would certainly like it to be.)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Everything sounds simple in my mind but I am sure there are some<br>
interesting gotchas with this option.<br>
</blockquote>
<br></div>
It's a bit harder than it looks, yes. The problem is that there are two notions of node identity in federation - what a node knows itself as (the local_nodename, defaulting to but not necessarily the hostname) and what other nodes know it as (the DNS name, ending up in the URI). Maybe if you are lucky then the two coincide, but I would not want to assume that. Plus federation links really connect clusters, which don't have DNS names anyway. And we want to drop messages at the upstream, for efficiency, so we only have the local_nodename to go on - but x-received-from contains URIs.<br>

<br>
So we need to sort that lot out before it can happen. Not impossible, but just a bit fiddly.<br>
<br>
Cheers, Simon<br>
<br>
</blockquote></div><br></div>