[zeromq-dev] Cloudless: Abstract Networking

[Amr Ali]

I hope this is the right mailing list to talk about projects related to 0MQ.

At my company we've been working on a multi-component, e-fraud detection and
intelligence project, we used 0MQ for communication across components including
complex processing of messages in logical sub-components.

Aside from my fascination with 0MQ's broker-less model, communication patterns,
and simple API; I've had to put considerable amount of time in developing
"devices" which implement certain design patterns to have a scalable and
maintainable code-base. Of course this is nothing against 0MQ, it's not meant to
do any of that. Although I see 0MQ act as a main enabler to that extra step.

The primary goal behind Cloudless (http://cloudless.io) is to cut short all the
boiler plate one has to develop to end up with a scalable code-base for the
majority of purposes.

Also Cloudless acts as a transparent consistent wrapper around 0MQ to abstract
API differences across versions to get developers to use 0MQ way of
communication instead of developing against library specifics.

I'd like to clarify my terminology a bit, specifically "devices" as this term
has been used for a wide range of purposes. What I mean by a device here means a
class or a grouping of code-bits that acts on or manipulates data it receives.
(e.g., ping-server, hub, switch, router, etc.)

The project is currently in beta and I intend to keep it in that phase till the
outermost API matures. There are some areas that definitely could use some
refactoring and optimization such as the polling over edges and edge-points
which is currently an O(n^2), I think it's not serious as the number of edges or
edge-points can't realistically grow larger than a handful but it could
definitely be done better in my opinion.

There's also a room for improvement by abstracting socket IDs in messages.
Perhaps a wrapper object is useful to identify socket IDs and ease things on the
developer's behalf, I don't know, didn't give it much thought, if you have
thoughts on it, I'd love to hear about it.

My current implementation of event-handling is not quite a reactor pattern but
more of a micro-reactor pattern where each device is it's own reactor; where one
starts with inheriting from a device and then implement on_recv() and from there
starts the event processing hierarchy.

I'm still indecisive about fully incorporating cryptographic facilities in the
library to help with secure message passing and authentication, but I've
developed a few on-top of libcrypto++ for [authenticated] block-ciphers, message
digests, MACs, and an exchanger interface for public-key encryption/authentication.

The library has a high test coverage, extensive API documentation using Doxygen.
Although there's no usage documentation except for the two examples on the site.

I've already listed the project on the labs page
(http://www.zeromq.org/docs:labs). I'd love to hear any and all
feedback/questions/ideas/criticism from the community.

Thanks!
-- 
Amr Ali

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120911/c9056b67/attachment.sig>