[zeromq-dev] contributing to 0MQ

[Martin Sustrik]

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:

http://www.zeromq.org/whitepapers: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):

http://www.zeromq.org/local--files/area:whitepapers/bc_csokas.pdf

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.

Martin