[zeromq-dev] Meetup in Chicago, Oct 20

[John Flanagan]

I wrote up a white paper while I was still at my last job, when I did a
prototype for them.  That's the kind of thing that happens when I receive
insufficient supervision at work, I go and do a research project. :)

Alas, I moved on, to a small startup where I started over and advanced the
idea quite a bit further.  So I don't have access to the original
presentation any more, and since I'm the only developer at the startup,
there's not a whole lot of point to a fresh writeup.  I suppose I should do
something along those lines anyway in case I get hit by a bus.  I suspect
you guys would make a good audience.

The elevator pitch runs something like this: ZMQ inproc allows atomic queue
messaging between separate threads of a single process.  What if you could
do atomic queue messaging between completely separate processes on the same
physical box?  This is trickier than it sounds, because you have to take
into account that the process on either end can die at any time.

The current system uses atomic queues stored in shared memory, and has a
one-way latency of around 3 microseconds, almost all of which is due to
thread sleep/wakeup.  Throughput is about 2.5 million messages per second.
I haven't tested making the apps busy-wait instead of sleeping/waking, but I
suspect that would bring the latency down to practically nothing, and
throughput would go through the roof.  It's on my list of things to try.

Getting messages between separate physical boxes requires another layer,
which is where something like ZMQ can come in.  I currently am doing my
box-to-box relaying of messages with direct TCP socket code, but I'm
considering doing a ZMQ implementation because the messaging model is
actually a pretty close fit.

On Thu, Oct 20, 2011 at 3:51 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> On 10/20/2011 03:05 AM, John Flanagan wrote:
> > I am only lurking the OMQ list lately, and just noticed this email
> > thread today.  I enjoyed chatting with you guys last time, and I'd like
> > to stop by again.  My current project has similar aims as OMQ (to be
> > honest, the core idea was inspired by the inproc implementation), but
> > differs VASTLY in implementation.  Might be interesting to swap ideas.
>
> Share a link :)
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111020/e3125f49/attachment.htm>