[zeromq-dev] contributing to 0MQ
Ildefons Magrans de Abril
ildefons.magrans at gmail.com
Tue Apr 20 12:55:43 CEST 2010
thank you very much for the detailed list. Points 2, 3 and 5 are
Can you please send me the whitepaper that you comment in point 5?
On Thu, Apr 15, 2010 at 6:35 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> Hi Indefons, John,
>> I am not a member of iMatix nor a developer on the 0MQ team, so am
>> being a bit rude by responding to your note - Martin S., please
>> forgive me!
> Well, you've worked on the VMS port plus COBOL and Fortran bindings, no?
> That makes you part of the team :)
> Actually, if anyone has any research ideas or would like to participate
> on research please shout! I am happy to see academic research on 0MQ
> happening. Although we've done a lot of research there was never enough
> time (or will) to publish it in more formal way than email or ad-hoc
> whitepaper placed on the website. That makes 0MQ look like it's missing
> formal theoretical background.
>> One of the most difficult areas with software the nature of 0MQ is
>> exactly the one you are thinking of: "Latency monitoring and
>> adjustment". Given reasonable SLAs between
>> systems/nodes/threads/whatever, it would be great to 1) examine the
>> QoS against the SLAs and 2) be in a position to monitor the state of
>> the system; even better, change parameters on the fly to alleviate
>> things such as congestion, hung clients, or whatever.
> Agreed. However, it may prove hard for a person without direct
> experience with production environment to do research of such research.
> It's up to Indefons to decide anyway.
> Some other topics off the top of my head:
> 1. Theoretical foundation for latency and throughput measurement. I've
> wrote a short whitepaper on measuring jitter:
> Similar documents for latency and throughput are missing still. This
> kind of research requires some experience with statistics.
> 2. As QoS in 0MQ is delegated to the networking layer, so any research
> on QoS would require messing with underlying infrastructure. Say "How to
> set up your network to get the best latencies." Similar theme was
> researched by Patrik Csokas (bachelor degree paper):
> 3. Very interesting research would be formally describing and getting
> the lockless algorithms used to back 0MQ queues. However, that seems a
> way off from your interests.
> 4. Interesting theme is unifying messaging API with Berkeley socket API.
> I can even imagine doing this work in the scope of IETF. The project
> could result in implementing a small wrapper library that would override
> the Berkeley socket API and allow to use 0MQ via standard POSIX APIs.
> 5. The topic of scaling messaging solutions to the Internet scale is big
> and underresearched area. Topic so wide would require a lot of
> commitment though. If you are interested in this I can send you a
> whitepaper we've written about it.
> If you want to go some other way, feel free to discuss it here. You'll
> probably get a lot of advice once the focus of the research is more clear.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev