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 <[email protected]>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:* [email protected] [mailto: > [email protected]] *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 < > [email protected]> 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 <[email protected]> > wrote: > > I guess nobody is interested in pluggable protocols. Thanks anyway. > > > > *From:* [email protected] [mailto: > [email protected]] *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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
