[nanomsg] Re: Introduction and questions
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 23 Jun 2013 08:54:10 +0200
Hi Jimmy,
I was excited when I saw the announcement for nanomsg, but until a few
days ago had entirely forgotten about it. Thanks for the tip on the
aio2 branch, Martin. Not to mention all of your hard work!
Thanks!
The internals of zeromq are somewhat . . . indigestible at this point,
but from the little I've poked around in nanomsg so far it seems like
a port would be FAR simpler.
I'm trying hard. Anyway, if there are pieces in nanomsg that you still
find indigestible, please to point them out and we can think about how
to make them more palatable.
I think a Go port could be much simpler and clearer due to Go having
done a lot of the groundwork already.
That's rather a compelling reason. It would yield, AFAICS a minimal
implementation of the protocol, with no low-level black magic needed in
C implementation.
And just in general two or more implementations keep specs honest and
makes it easier to see when the code and the spec diverge.
Yes. Second implementation would raise the problem of the protocol.
Currently, there are several options:
1. Use the original ZeroMQ protocol I've devised back in 2008. The
problem with that is that even then it was meant as a throw-away
protocol. From today's point of view, it's clear it misses couple of
features (e.g. ID of the messaging pattern). It also coallesces the
messaging layer with the presentation layer (multi-part msgs) which
results in convoluted code.
2. ZeroMQ folks have proposed ZMTP/3.0 protocol, which, AFAICS is
basically a security negotiation protocol, thus, mostly orthogonal to
the core messaging functionality.
3. We can simply create a new protocol. Sounds like the best option to
me, but it would mean more work with writing the protocol down etc. On
the other hand, writing it down would allow us to do that in RFC format,
so that it can be easily passed to IETF when the time comes.
When I have some time I'm going to poke around the aio2 branch and try
to come up with a design for the Go version--or at least some good
questions to pester Martin with ;)
Go for it!
Feel free to berate me for any naive assumptions I've made.
One thing to keep in mind is that by creating a new implementation has
the drawback of not automatically getting new features from nanomsg. If
someone, say, implements InfiniBand transport for nanomsg, the Go
implementation wouldn't get it for free. Same applies to possible new
messaging patterns.
Martin
Other related posts:
