reply instead of reply to all...<br>Thank you ben...<br><br><div class="gmail_quote"><br><div class="Ih2E3d">On Tue, Nov 11, 2008 at 6:35 AM, Ben Hood <span dir="ltr">&lt;<a href="mailto:0x6e6562@gmail.com" target="_blank">0x6e6562@gmail.com</a>&gt;</span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
Peter,<br>
<div><br>
On Tue, Nov 11, 2008 at 4:42 AM, Peter Silva &lt;<a href="mailto:Peter.A.Silva@gmail.com" target="_blank">Peter.A.Silva@gmail.com</a>&gt; wrote:<br>
</div><div><br>
</div></div><div class="Ih2E3d">This discussion (as an extension to the thread Kirk started) is going<br>
on too long. If defering the routing type to the bindings is as<br>
trivial as you maintain, then please enlighten me with a proof of<br>
concept written in a language of your choice. It would have not have<br>
to be AMQP specific, just something that shows the basr fundamental<br>
routing lookup mechanism based on the data structures you are<br>
proposing.<br>
<br>
Code speaks louder than words and I would love to be proven wrong.</div></blockquote><div><br>Funny you should ask!<br><br>I would really appreciate someone who understands switching having a look at our switch.&nbsp; We&#39;ve only used it internally so far, but I whipped up some .deb&#39;s in honour of your request:<br>

<br><a href="http://metpx.sf.net" target="_blank">http://metpx.sf.net</a>&nbsp; <br><br>It&#39;s a third generation switch, build from blackbox re-engineering of the other two generations.&nbsp; There is developer documentation to get a loopback configuration working for testing, it&#39;s very weather oriented right now.&nbsp;&nbsp; We&#39;ve been working on it for a few years, but the weather messaging community is, well, kind of scattered, so the installed base is 1.&nbsp; It&#39;s a very enthusiastic 1, mind you :-)<br>

<br>concept mapping:<br><br>AMQP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MetPX<br>---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----------<br>Exchange&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Receiver<br>Queue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sender<br>Binding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Routing<br><br>bindings work with two verbs, accept and reject.<br>

We differentiate between regex&#39;s and direct mappings for efficiency reasons (use a table for the direct ones.)<br>and yeah, we&#39;re stuck with a linear search through regex&#39;s, which we try to minimize.&nbsp; <br><br>

We didn&#39;t do routing that matches to exchanges, but almost all the exchanges use the same routing tables. It implements the rest of the routing algorithms I have described in python.&nbsp; Ruthless simplicity meant that our first database was done using 1 file per message on a raw file system.&nbsp; It turns out we can deliver hundreds of messages per second with that storage and FTP, which was good enough for us.<br>

<br>The packaging is kind of rough, internal people use it a little differently.&nbsp; We&#39;ve been using debian packages for a few months, but file layout is a little different. <br><br>The routing is actually a very small part of the code a few hundred lines at most.&nbsp; Most of it is protocol drivers.<br>

<br>The reason for me asking these questions is to understand how to add AMQP support to metpx. <br><br>ready to answer questions, on or offline. <br><br><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<div><br>
&gt; On the other hand,<br>
&gt; going through long lists of regular expression evaluations can kill<br>
&gt; performance.<br>
<br>
</div>:-)</blockquote></div><div><br>the key is minimizing the number that have to be searched for each routing event.&nbsp;&nbsp; If you treasure speed over flexibility, then just don&#39;t put any regex&#39;s in your routing.&nbsp;&nbsp; <br>
<br>
Another difference in the design point, is that metpx came from dealing with existing exchanges, and did not have the luxury of defining it&#39;s own key syntax.&nbsp;&nbsp; Data producers are often limited in the names they can supply, and consumers with what they receive (remember, we deal with files, our keys are essentially file names.)<br>

<br>If we insisted on file naming conventions, we ended up having to implement separate glue elsewhere to rename things we received into the file naming convention the switch required.<br>&nbsp; It made sense to add regex comprehension to the switch itself to derive routing keys from the arbitrary file names we would receive.<br>

</div></div><br><br><br>
</div><br>