[nanomsg] Re: modular nn_device

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Fri, 13 Jun 2014 07:58:18 +0200

Hash: SHA1

Hi Drew,

> I’m wondering if there is any interest in improving the modularity
> of nn_device.
> If you look at the current design, there are a bunch of functions
> that you get as a set:
> * nn_device, which performs a series of checks, none of which are 
> configurable * A series of nn_device_nway functions that implement
> various polling schemes * an nn_device_mvmsg function that copies a
> message from here to there
> Lately I have been writing some devices that are roughly 90%
> nn_device and 10% something else.  For example I have an
> nn_caching_device that learns how to answer certain requests
> without asking the other socket. I have an nn_hub_device that sends
> a request to one of several workers based on criteria.  I have
> devices that know how to bridge protocol types that are not
> ordinarily compatible.  etc.
> My current strategy to build these is basically to copy device.c
> into a new file and make edits as appropriate, but obviously this
> is wasteful and is a poor design for the kind of experiments I’m
> doing.
> I’m wondering if there’s interest in me working on making device.c
> more modular.  Specifically I’m thinking about creating some kind
> of vfptr structure where you can specify a device by creating a
> struct with function pointers that define the device’s behavior, so
> that I custom devices would be able to override the base device
> piecemeal rather than all at once.

Yes, there's definitely a merit in making the code more modular.

Technically, I would make it an internal extension point similar to
transport.h or protocol.h that we have in place currently.

There's one other concern with respect to devices that I would like to
address in some way: Namely, that there are devices and device-like

What I mean by that is that "device" is something that preserves the
overall behaviour of the protocol. I.e. if it is placed into pub/sub
topology, the topology would still distribute the messages to all
subscribers. If placed into req/rep topology, the topology would still
load balance the requests among the workers in a cluster. Et c.

A non-device is an application that happens to interconnect two
disparate topologies. Say an application that gets data from a pub/sub
topology and uses a local req/rep cluster to process them.

I am not sure whether or how this would influence the design, but it
is at least something to think about.


Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Other related posts: