[nanomsg] Re: Language binding vs custom network protocol implementation
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sun, 14 Sep 2014 15:14:29 -0700
I found many advantages in building a pure go version. I think I get better
latency than a native binding would plus I am able to make use of go
concurrency and a bunch of nice features in idiomatic go.
I imagine this would be true for other languages as well. The wire protocol is
dead easy. The hard part is getting the reconnect and other pattern semantics
correct. I think I've done that and I was able to do this in a relatively
small number of days of coding.
If you have questions about mangos I would be happy to help.
Sent from my iPhone
> On Sep 14, 2014, at 1:26 PM, Mingfai <mingfai.ma@xxxxxxxxx> wrote:
>
> hi Dirkjan,
>
>> On Mon, Sep 15, 2014 at 12:39 AM, Dirkjan Ochtman <dirkjan@xxxxxxxxxx> wrote:
>> On Sun, Sep 14, 2014 at 5:37 PM, Mingfai <mingfai.ma@xxxxxxxxx> wrote:
>> > So I basically want to figure out what kind of magic the C binding does.
>> > :-)
>>
>> Consider looking over this page, which might give you some ideas:
>>
>> http://nanomsg.org/documentation-zeromq.html
>
> it said to be a comparison with ZeroMQ but you are right its really useful to
> understand NanoMsg's magic.
>
>> I'd consider the threading model, the state machines and the zero-copy
>> support all pretty involved. Also Martin is pretty experienced at this
>> kind of thing, so you'll miss all of that experience in building out
>> your solution.
>
> I believe thread model is the easiest part among the three as there are
> equivalent or more Java-ish way.
> I saw some state machine diagrams from the mail list last year, hope they
> will help in understanding the design
> https://drive.google.com/folderview?id=0Byd_FTQksoKLM3ExekJMVnZJU0U&usp=sharing
> for zero-copy, be honest I don't fully understand RDMA and shmem but they
> sounds powerful. In Java, esp with Netty, it's easy to use direct ByteBuffer
> that basically map the data in memory outside the JVM heap without any need
> to copy to the JVM.
>
>> You could look at improving the existing bindings or starting your own,
>> instead?
>
> I wouldn't start a new binding. The current two binding are fine. The JNI one
> is too C/native and too hard to use for me. The JNA binding I'm using is
> reasonable close to Java. nn_poll needs to be add to it but there is no much
> difficulty. And I made a couple of pull requests already.
>
> Binding usually hard to deploy in Java. There are exceptional such as there
> is a LevelDB binding that uses HawtJNI that just deploy different native
> build to Maven (Maven is like a dump version of NPM/Gem/PIP in Python), so
> there is no need to pre-build the native library that is sometimes a show
> stopper for Java people to consider a library.
>
>>
>> In any case, having independent implementations is still great (look
>> at Garrett's Go implementation mangos, for example).
>
> Thanks. I studies Mangos' source code and as Go lang is readable to me, this
> is a factor I considered in assessing the difficulty of a Java
> implementation. After all, I do not aim at a full implementation but just one
> or two use cases such as for a Java client to subscribe.
>
> JeroMQ to ZMQ is a good example of pure Java implementation. It's not too
> shabby in compare the C++ one.
> https://github.com/zeromq/jeromq/wiki/Performance
>
> Thanks for your feedback
>
> Mingfai
>
>> Cheers,
>>
>> Dirkjan
>
Other related posts:
