[nanomsg] Re: hello, status, etc.

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx, Ondřej Kupka <ondra.cap@xxxxxxxxx>
  • Date: Sun, 23 Feb 2014 10:55:51 -0800

Excellent. 

I’ve been looking more at zenio, I think its too immature, and really I’d like 
to start from scratch.

I definitely want to make better use of channels and goroutines.  This should 
fit quite nicely with Go’s paradigms.  I’ve been doing a lot of paper design in 
the past 24 hours… will start actually coding something in the next few days, 
and will post a git URL for collaboration when ready.

-- 
Garrett D'Amore
Sent with Airmail

On February 23, 2014 at 4:28:21 AM, Ondřej Kupka (ondra.cap@xxxxxxxxx) wrote:

Didn't know about zenio. I must say that having a native Go implementation of 
nanomsg would be pretty useful and perhaps not that hard. Cgo calls are 
expensive and it would also make it possible to use Go patterns instead of 
fighting the original interface.
Speaking of zenio, not sure we need both zmq and nn. They are basically doing 
the same thing, so I would not waste resources doing both at once, at least at 
the beginning.
And of course I would love to help. Unfortunately I don't have so much time. 
Perhaps I could review some code if it would bring some benefit.

Cheers,
Ondrej Kupka (tchap on GitHub)

On Feb 22, 2014 8:56 PM, "Garrett D'Amore" <garrett.damore@xxxxxxxxx> wrote:
Hi all,

I have recently started looking at nanomsg as a superior alternative to zeromq, 
and I’m pleased with what I’ve found.  I was able to put together a JSON-RPC 
server of my own device on top of nanomsg really quickly.   I was quite pleased 
with the result.  Admittedly, I’ve not tried building any of the other patterns 
other than REQ/REP yet, but I don’t expect too many surprises.

That said, I see that the upstream github repo is rather devoid of activity 
lately.  I’d like to understand whether this is due to lack of resource, or a 
feeling that the project is sufficiently complete to not require further 
investment?

Are folks using this stuff in production yet?  Are there gotchas that I should 
be aware of?  I don’t see anything obvious in the code, but would like to know 
what experiences folks have with it so far.  (Yes, I know its officially 
“alpha”, but reading the code, and understanding the underlying design, I feel 
*far* more inclined to trust this project’s alpha quality code than some other 
projects’ production stuff. :-)

At the same time I’m exploring Go, and would like to bind the two together in 
native Go rather than building against external C.  It seems that Go has a 
concurrency and messaging model that is more naturally suited to nanomsg, and 
based on conversations I’ve had with one of the Go developers (Aram 
Hǎvǎrneanu), I am thinking that linking libnanomsg.a to Go robs the application 
of some of the benefits of Go’s excellent concurrency and messaging.

I did find the zenio project here https://github.com/op/zenio and am starting 
to work with it.  I need to extend it to support the ipc:/// scheme, so that 
wil be my first area of enhancement.  But it seems like this project really 
could use more investment, and its something I’m keen to do.  (Has anyone else 
here tried using zenio outside of the author?)  Admittedly I’m more interested 
in creating a pure Go implementation of just nanomsg than I’m in trying to also 
support zmq — it seems like that is better addressed in a separate project, 
although having a higher level abstraction model (interface) that could support 
either project doesn’t seem like a terrible idea — that should just be a matter 
of defining the proper method signatures.

I’m also concerned about the stability of the wire protocol, as what I’m really 
looking at is investing into enhancing (if based upon zenio) or even creating 
(if starting fresh) a completely independent implementation of the protoocols.  
(Again, this has *nothing* to do with not being happy with libnanomsg in the 
context of a C application — in fact I really like the library both from an 
interface and from an implementation standpoint.  But writing for C is 
different than writing for another environment, and I believe we can make a 
*superior* implementation *for Go* by doing it in Go natively.)  I found the 
RFC drafts, and they seem to mostly match the code, apart from the fact that 
the current code sends version 0 instead of 1.  Are there other differences in 
the code, or planned that I should know about?

I’d also be interested in extending nanomsg to operate over kinds of 
transports.  I’m specifically interested in tunneling it through SSL/TLS and 
HTTPS/websocket.  (This would help allow it to reach across the internet 
without requiring a VPN.)  It seems like this would be a fairly 
straight-forward task to do, just creating additional transports in the 
transport/ directory.   Are there already such efforts underway?  Are there 
strong opinions about such efforts one way or the other?  (Doing this in Go 
would be almost child’s play given a version that works with TCP.  Making it 
work in C means bringing in other libraries like OpenSSL or libcurl,  unless 
one wants to write those protocol implementations from scratch which I most 
assuredly do *not*! :-)

Anyway, sorry for the long rambling message, and thanks for any advice or 
pointers provided! 

-- 
Garrett D'Amore
Sent with Airmail

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 02-2014