[nanomsg] Re: Language binding vs custom network protocol implementation
- From: Mingfai <mingfai.ma@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 15 Sep 2014 02:20:14 +0800
hi Achille,
On Mon, Sep 15, 2014 at 12:35 AM, Achille Roussel <achille.roussel@xxxxxxxxx
> wrote:
> Hello,
>
> Nanomsg also provides features like automatic reconnections, automatic
> send retries, efficient memory management, polling, proxy... as well as
> checks at the socket level that a program isn't trying to misuse a protocol
> (sending multiple requests on a REQ socket without reading the responses
> for example).
>
This is a good list of information and I am thinking about them one by one.
Some of the items are provided by Java NIO framework/library, e.g.
- Netty does buffer pool for memory management (and efficient or not,
Java does GC), and manage the polling. There are API event for detect
connection failure and allow programmatic retry/reconnect.
- A main issue is to ensure the implementation compatible with
Scalability Protocols. But after I sniffed the NanoMsg packets, the
protocol is so simple and it seems not hard to get it right.
> The library also abstracts the transport layer so that you can use the
> same code to do network, IPC and in-process communicators.
>
> What about writing a better Java binding yourself?
> Or improving one if the existing Java bindings?
> That would probably be just as much work than building your own
> implementation of scalability protocols, and it would be if great use to
> the community.
>
>
A full implementation with all NanoMsg features may be hard, but to tackle
only one or two use cases, e.g. tcp + pub/sub, it's a different story.
it seems to me the work to build a pure Java solution, or just a Sub
client, is significantly easier.
Latency is my main concern. Right now I'm using JNanoMsg using nn_recv to
blindly poll message (get exception when there is no msg) and it does work
but I think using nn_poll to check for message before polling is better.
Anyway, I'll use the current implementation to establish some baseline
performance figures to decide the next step.
It seems to me these C/native library stuff are quite an alien in the Java
space, and JNanoMsg is already more natural to Java developer and
reasonably easy to deploy. There does exist other binding approach to make
the deployment easier, but the API and performance wouldn't be better.
btw, I actually made a couple of pull requests to JNanoMsg.
Thanks for your comments and questions.
Mingfai
> Achille Roussel
> +1 415 490 6339
>
> > On Sep 14, 2014, at 8:37 AM, Mingfai <mingfai.ma@xxxxxxxxx> wrote:
> >
> > hi,
> >
> > for pub-sub and push-pull, probably the other as well, the
> wire/transportation/network protocol of NanoMsg is quite simple,
> apparently, the first conversation to establish the protocol/pattern, then
> sending message is all about a 8-byte header/length and then payload. Every
> port can bind for only one protocol.
> >
> > given the network protocol is simple, what kind of advantage we can get
> from using a language binding in compare to just implement the network
> protocol?
> >
> > My case is using Java, and Java has very mature async network libraries,
> e.g. Netty, that allow me to implement a subscriber, or maintains the
> channels of inbound connections as publisher, easily. On the other hand,
> the two bindings are relatively immature and harder to use.
> >
> > One step backward, the reason I wound want to use NanoMsg (at least it's
> protocol) is to avoid design my protocol to use defined patterns, and allow
> interoperability with non-Java platform.
> >
> > So I basically want to figure out what kind of magic the C binding does.
> :-)
> >
> > thanks,
> > mingfai
>
>
Other related posts:
