SP (nanomsg) in Pure Go
I'm pleased to announce that this past weekend I released the first version of my implementation of the SP (scalability protocols, sometimes known by their reference implementation, nanomsg) implemented in pure Go. This allows them to be used even on platforms where cgo is not present. It may be possible to use them in playground (I've not tried yet!)
This is released under an Apache 2.0 license. (It would be even more liberal BSD or MIT, except I want to offer -- and demand -- patent protection to and from my users.)
I've been super excited about Go lately. And having spent some time with ØMQ in a previous project, I was keen to try doing some things in the successor nanomsg project. (nanomsg is a single library message queue and communications library.)
Martin (creator of ØMQ) has written rather extensively about how he wishes he had written it in C instead of C++. And with nanomsg, that is exactly what he is done.
And C is a great choice for implementing something that is intended to be a foundation for other projects. But, its not ideal for some circumstances, and the use of async I/O in his C library tends to get in the way of Go's native support for concurrency.
So my pure Go version is available in a form that makes the best use of Go, and tries hard to follow Go idioms. It doesn't support all the capabilities of Martin's reference implementation -- yet -- but it will be easy to add those capabilities.
Even better, I found it pretty easy to add a new transport layer (TLS) this evening. Adding the implementation took less than a half hour. The real work was in writing the test program, and fighting with OpenSSL's obtuse PKI support for my test cases.
Anyway, I encourage folks to take a look at it. I'm keen for useful & constructive criticism.
Oh, and this work is stuff I've done on my own time over a couple of weekends -- and hence isn't affiliated with, or endorsed by, any of my employers, past or present.
PS: Yes, it should be possible to "adapt" this work to support native ØMQ protocols (ZTP) as well. If someone wants to do this, please fork this project. I don't think its a good idea to try to support both suites in the same package -- there are just too many subtle differences.
This is released under an Apache 2.0 license. (It would be even more liberal BSD or MIT, except I want to offer -- and demand -- patent protection to and from my users.)
I've been super excited about Go lately. And having spent some time with ØMQ in a previous project, I was keen to try doing some things in the successor nanomsg project. (nanomsg is a single library message queue and communications library.)
Martin (creator of ØMQ) has written rather extensively about how he wishes he had written it in C instead of C++. And with nanomsg, that is exactly what he is done.
And C is a great choice for implementing something that is intended to be a foundation for other projects. But, its not ideal for some circumstances, and the use of async I/O in his C library tends to get in the way of Go's native support for concurrency.
So my pure Go version is available in a form that makes the best use of Go, and tries hard to follow Go idioms. It doesn't support all the capabilities of Martin's reference implementation -- yet -- but it will be easy to add those capabilities.
Even better, I found it pretty easy to add a new transport layer (TLS) this evening. Adding the implementation took less than a half hour. The real work was in writing the test program, and fighting with OpenSSL's obtuse PKI support for my test cases.
Anyway, I encourage folks to take a look at it. I'm keen for useful & constructive criticism.
Oh, and this work is stuff I've done on my own time over a couple of weekends -- and hence isn't affiliated with, or endorsed by, any of my employers, past or present.
PS: Yes, it should be possible to "adapt" this work to support native ØMQ protocols (ZTP) as well. If someone wants to do this, please fork this project. I don't think its a good idea to try to support both suites in the same package -- there are just too many subtle differences.
Comments
- Did you try gccgo (4.9 branch as that tracks Go 1.2, easy to install with homebrew)?
- In Go 1.3 there will be a generic Pool implementation, but the code can already be copied to 1.2, even though it's pretty unoptimized at the moment (as they say themselves). Perhaps that could help with the buffer churn or at the very least help prove that the buffer churn _is_ actually troublesome.
- Go actually provides some good profiling tools in the toolchain, could be handy for finding out where (if) the bottlenecks are.
Very cool project and implementation, keep it up!
B.t.w.: my twitter handle is @alazyleopard
- Did you try gccgo (4.9 branch as that tracks Go 1.2, easy to install with homebrew)?
- In Go 1.3 there will be a generic Pool implementation, but the code can already be copied to 1.2, even though it's pretty unoptimized at the moment (as they say themselves). Perhaps that could help with the buffer churn or at the very least help prove that the buffer churn _is_ actually troublesome.
- Go actually provides some good profiling tools in the toolchain, could be handy for finding out where (if) the bottlenecks are.
Very cool project and implementation, keep it up!
B.t.w.: my twitter handle is @alazyleopard