Hello, Is there on a git repo somewhere already ? I'd be very interested in having a look at it.
Kr, Diego Duclos On Thu, Apr 10, 2014 at 9:53 AM, Pieter Hintjens <[email protected]> wrote: > Hi Michael, > > This sounds great. My advice is to make small steps, solving one > problem at a time, rather than aiming for ideal solutions. I'd love to > see compile-time pluggable protocols come onto master, and be used, > before we think about making this a runtime thing. Keep things simple, > don't solve problems we don't have (yet). > > -Pieter > > On Thu, Apr 10, 2014 at 5:21 AM, Michael Holmwood <[email protected]> > wrote: > > Greetings All, > > > > I am currently involved in a project that aims to add SCTP as a transport > > protocol to ØMQ. So far, we have managed to get SCTP working fine, we > just > > needed to add the ability to modify heart beat and add addresses for > > multi-homing. The multi-streaming part is going to be the most difficult, > > but I don't think we will be having any problems adding this. > > > > Back in February, I recall a message that was posted on the mailing list > > regarding pluggable transport protocols. Having spent some time looking > at > > the ØMQ source code, I determined that I could add this without too much > > trouble. So we have made some of the necessary changes, and have both > SCTP > > and TCP working as pluggable protocols, with TCP being the default > option. > > We have tested the performance with pluggable and non-pluggable (with > TCP) > > and noticed no difference. > > > > At the moment, there is no way to add protocols after ØMQ is compiled, > which > > is the next thing we needed to look at. We have considered a few options: > > > > 1) Leave it the way it is, having protocols only added when ØMQ is > compiled. > > I have seen something similar used in the UDT library, but this was with > > pluggable congestion control algorithms. http://udt.sourceforge.net/ > > > > 2) Provide something in the API to enable protocols to be added using > shared > > libraries. > > > > 3) Provide a mechanism to register new protocols via the API using > factory > > objects/functions. > > > > I am quite keen on option 3, however it would be good if I could get some > > input from the community before proceeding. One thing to note is that it > > only currently works with Linux, as this is what our client has > requested, > > but would look at modifying the code to work with both. > > > > The interface that I have created requires that the protocols be added > using > > classes created in C++, so I guess I might have to look at modifying it > to > > work with C or provide a mechanism to provide the appropriate functions > > using pointers. > > > > Regards, > > > > Michael Holmwood. > > > > > > > > _______________________________________________ > > 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
