[zeromq-dev] Protocol Plugins

Diego Duclos diego.duclos at palmstonegames.com
Wed Feb 12 19:19:59 CET 2014


I very much like this idea and would like to see this in. If a proper spec
is made, I'll likely be adding this to NetMQ.


On Wed, Feb 12, 2014 at 6:03 PM, Lyle Thompson <lthompson at ixiacom.com>wrote:

>  Hi Guys,
>
>
>
> Thanks for your responses. I definitely appreciate it. But maybe I said
> SOCKS too early in the email J The main idea was to make protocols
> pluggable (i.e. introduce protocol "drivers") so the main code base
> wouldn't be burdened with odd protocols that few people use anymore (like
> SOCKS), and 0mq wouldn't have to be modified to support them. This looks
> pretty easy to do at link time, but I would be more interested to do a
> run-time binding. I don't think there is a generic dll/so framework that
> would make sense to use within 0mq, so I'm thinking about introducing an
> api, something like (this is just pseudo code because I'm not on the
> machine where I checked out the code, and I'm too lazy to look up the
> specific details):
>
>
>
> ECODE addProtocol(ZMQ_CONTEXT context, IProtocol Descriptor *pProtoDescr);
>
>
>
> Where IProtocol would be an interface/struct with something like:
>
>
>
> char* getProtocolId();
>
> char* getProtocolDisplayName();
>
> IConnectHandler connectHandler;
>
> IDisconnectHandler disconnectHandler;
>
> IReadHandler readHandler;
>
> IWriteHandler writeHandler;
>
> IErrorHandler errorHandler;
>
>
>
> Then, wherever the current code uses if (protocol == "xxx') { do
> something; } it would instead do something like:
>
>
>
> IProtocolDescriptor protoDescr =
> context.protoRegistry.getProtocol(protocol);
>
> If (protoDescr == null) {
>
>     Throw exception;
>
> }
>
> protoDescr.connectHandler.connect(); // or whatever it was about to do.
>
>
>
> Of course the handler could be cached so the lookup wouldn't have to
> happen every time (maybe even cached on the context).
>
>
>
> With this, the user (programmer) would then just have to write a protocol
> handler (e.g. SOCKS plugin) and call addProtocol after initializing 0mq and
> he'd be off and running without having to modify the 0mq code base.
>
>
>
> Thanks!
>
> Lyle
>
>
>
>
>
> *From:* zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] *On Behalf Of *Benjamin Cordes
> *Sent:* Wednesday, February 12, 2014 12:08 AM
> *To:* ZeroMQ development list
> *Subject:* Re: [zeromq-dev] Protocol Plugins
>
>
>
> P.S. as I understand the tao of 0mq, the idea is to get rid of all these
> idiosyncratic patterns. for example in the socks5 RFC you have this, see
> below. the document was written in 1996. now its 2014, so it should be
> possible to do this in better ways, unless you have to talk some other
> server which only speaks that language (in that case you can write a
> mapper).
>
>   The values currently defined for METHOD are:
>
>
>
>           o  X'00' NO AUTHENTICATION REQUIRED
>
>           o  X'01' GSSAPI
>
>           o  X'02' USERNAME/PASSWORD
>
>           o  X'03' to X'7F' IANA ASSIGNED
>
>           o  X'80' to X'FE' RESERVED FOR PRIVATE METHODS
>
>           o  X'FF' NO ACCEPTABLE METHODS
>
>
>
>
>
> On Wed, Feb 12, 2014 at 9:01 AM, Benjamin Cordes <
> benjamin.l.cordes at gmail.com> wrote:
>
> you can do this quite easily I believe with existing patterns. one auth
> server takes in requests. that server checks the request and if it is valid
> forwards the request to the outside world, sending back the response. here
> is the RFC for socks5: http://www.ietf.org/rfc/rfc1928.txt I assume you
> only want to connect to TCP/IP, not UPD?
>
>
>
> On Wed, Feb 12, 2014 at 3:05 AM, Lyle Thompson <lthompson at ixiacom.com>
> wrote:
>
>   I guess nobody is interested in pluggable protocols. Thanks anyway.
>
>
>
> *From:* zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] *On Behalf Of *Lyle Thompson
> *Sent:* Monday, February 10, 2014 3:11 PM
> *To:* ZeroMQ development list
> *Subject:* [zeromq-dev] Protocol Plugins
>
>
>
> Hi ZeroMQ experts,
>
> I am investigating how one might add SOCKS proxy support to 0mq, and of
> course there are several options. But I was thinking that the most elegant
> would be to add support for a "socks" protocol to 0mq. I took a look at the
> source code, and I was a bit surprised to find that the protocols are not
> pluggable. At the first level, I don't think this would be very hard to do
> (at least for **some** of the protocols); Just add a registration
> mechanism and change the code that is executed as the result of hard-coded
> protocol checks into calls through a table of available plugins.
>
> This would make it a bit easier to add new protocols (especially if they
> are similar or running on top of existing ones, as is the case for SOCKS).
> Presumably, one would just need to compile the module and link it into the
> code via the make file.
>
> Of course it would be nicer if it were dynamically linked (i.e. the
> "second level"), but I don't know of a platform independent way to do this
> that would make sense for 0mq. Of course it could be done with #ifdefs and
> what not, but would it be worth it?
>
> My motivation is that my company uses 0mq in a commercial product. And
> while we don't mind contributing, we'd rather contribute a general
> improvement than a very specific one (SOCKS), that many people would not
> need or want.
>
> I know this is a very high-level idea at this point, so blast away and
> let's see if there's anything left that worth implementing J
>
> Thanks,
>
> Lyle
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140212/afd2d095/attachment.htm>


More information about the zeromq-dev mailing list