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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
