[nanomsg] Re: modular nn_device
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 13 Jun 2014 07:58:18 +0200
-----BEGIN PGP SIGNED MESSAGE-----
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
non-devices.
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.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTmpL6AAoJENTpVjxCNN9YAuMH/RbWQQOMNVyLIvjT+K6JxBBF
wQPfZxem6y2iJnKULufGxztZf68vvFvWGI3pgrQ95CxUxQJM5OsvE0FYu6mpUsJO
A1dRDgmC3PlTP3Us5bBFNVvzvqVZW16xJP755GyITWj5XdmuyjX3QKSt19zWwueZ
dXKX2Htj4bvi6EtwBTz+m0bCCdfoLAV2y0d0PWfW635vJmnqYNS/JHh/elYSoxTW
VSDTIqjcB287Bwj3yhwwkitMDsVkucWBg0MfoVBd5VLhYsNTpIC1shdmMkwnWnve
A5AZTk5nwpqvnCDKmP+mlKySRoT6TR+35L0UukmoDnl4r2kpeXmvSBz3YhoHUGw=
=lfFk
-----END PGP SIGNATURE-----
Other related posts:
