[nanomsg] Re: Introduction and questions
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 22 Jun 2013 10:00:29 +0200
Hi Gonzalo,
1. Is it intended to support Win32 and Linux / UNIX as "first class
citizens"? I am referring in particular to "ipc://" support under Win32.
Yes.
The problem with IPC on Windows is that Windows NamedPipes (equivalent
of UNIX domain sockets) only work with IOCP API which is very different
to classic BSD socket API. There have been several attempts to make
ZeroMQ work with IOCP, but none have succeeded.
Anyway, nanomsg (aio2 branch) has working support for IOCP, so adding
IPC transport based of Windows NamedPipes should be rather easy.
2. Related to #1: is nanomsg based on AIO or is it based on poll / epoll
/ whatever?
On UNIX-y systems it's poll/epoll/kqueue. On Windows it's IOCP.
3. Given the engineering roots of the project, would you say it should
be easier to delve into the code of nanomsg, than to do the same for
0mq? I expect the answer would be "yes", but wanted to confirm. Is there
any architectural documentation / diagrams that could help a newbie get
on board?
I hope so. ZeroMQ codebase is very complex and thus it's hard to make
substantial contributions to. Thus, one of my goals with nanomsg was to
make the code easy to follow. If you are going to look at it though,
check aio2 branch which uses state machines to make the code more
comprehensible.
4. Is anybody working on a Java binding for nanomsg? If not, I think I
can cook something up in a short period of time, if there is interest.
I am not aware of anybody. It would be nice if you gave it a try. If you
decide to do so, give a bit of thought to licensing. One of the
important changes in nanomsg is to move from LGPL to MIT license.
5. Has there been any discussion about reimplementing nanomsg on a
different language, rather than implementing a binding for that
language? I take this idea from JeroMQ, which implemented the whole of
ZeroMQ in Java, bypassing the need to create a JNI binding, depend on a
native library, etc. I admit I used to think this was the wrong
approach, but I am not so sure anymore... Anyway, I would be interested
in exploring this alternative for Go, if nobody is doing this.
You can try to do that but it's quite a lot of work. In any case I would
wait until first alpha release of nanomsg -- which is to come shortly
anyway.
Martin
Other related posts:
