[zeromq-dev] contributing to 0MQ
sustrik at 250bpm.com
Thu Apr 15 19:35:31 CEST 2010
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.
More information about the zeromq-dev