[zeromq-dev] Preliminary results of voting

Martin Sustrik sustrik at fastmq.com
Tue Sep 2 18:28:25 CEST 2008


Hak,

Thanks for the comments. This is the kind of feedback I've hoped for!

See my replies inlined.

Martin

Hak Mem wrote:

> 
> 1. Wildcard at the end off the string is ok to get started
> 2. Having precompiled subjects would work to also get started...
>  
> In case #1, the utility of non-terminal wildcards in the selector string 
> goes up the more 0MQ is used e.g. subscribe to all fills - trade.*.fills 
> instead of trade.*. Furthermore, I would say if you are going to relax 
> any of the above constraints - #1 should be relaxed ahead of #2. The 
> primary drawback of #2 is the onerous nature of precompilation rather 
> than loss of functionality - this would typically mean a saturday 
> morning cycling of the 0MQ infrastructure when there is no traffic as no 
> market is open.

Yes. That was my idea - recompile the topics on EOD if needed. That way 
we can eliminate latency peaks that would otherwise occur when there's 
new symbol introduced.

> I also voted for one of my favorite features - but I would rather that 
> the 0MQ team focus on the features that will lead to the widest adoption 
> and the rise of a vibrant user and developer community around it. I 
> would posit that conferring longevity (open source immortality?) on 0MQ 
> is a far more critical goal.

More than agreed. However, low-latency messaging is quite an obscure 
field of interest and most FOSS developers don't understand it or even 
don't understand what it's good for. To establish a community, it is 
thus crucial to get feedback from people like you, confronting 
real-world challenges of it on daily basis.

> Some background - I work in an smallish trading organization (<200 
> people) where we own licenses to Tibco/Elvin and LBM's 29 west in 
> addition to market data system built on another messaging system whose 
> API is hidden to us. Nothing would delight us more than a *viable* open 
> source solution which will be there for a while and free us from vendor 
> lockin or the threat of end of product lifecycle event (e.g. elvin).

Yes. That was basically the idea behind the whole project.

> I would suggest that topic based routing and a windows port take the 
> highest precedent. Even more critical in the financial space would be 
> the ability to interface 0MQ to an RTD server. Sexy - no. Mundane - yes. 
> Useful - very. This "feature" will enable pumping of data in to Excel - 
> you know the value of that from walking on any trading floor. We hacked 
> an RTD interface for Tibco ourselves about 5 years ago and now locked 
> into that vendor since all our spreadsheets use that. No other vendor 
> has had the foresight to provide an RTD interface - I wonder if these 
> vendors are blind or just ......

Oh my. I know. This is kind of infrastructure that has to be built over 
0MQ one day. I somehow hope that the community will help with this kind 
of stuff...

> The surprise that Martin expressed at the result of the voting shows 
> that voters - while well meaning - are clueless about hardware latencies 
> and costs. In our world, even if we are coloed at the various exchanges 
> (and we are coloed at almost every one of them) data still takes 100s of 
> us to get to us. Shaving 10-20us at the extreme cost and *complexity* of 
> moving to IB or Myrinet stacks is not worth it.

Yes, that's my view of trader's preferences as well. Still, there are 
some very special users (like stock exchanges) that need *very* low 
deterministic latencies.

> Hence, I reiterate, the features that take precedence are those which 
> will gain 0MQ wider acceptance. In this case the interests of the the 
> user community and FastMQ are aligned.  Everyone wins if 0MQ wins.

Agreed. That's why we opted to provide different language bindings 
shortly. Having access to the product from different languages will 
enable much more people to use it and possibly contribute back to the 
project.



More information about the zeromq-dev mailing list