Hmm, on gmail these appear as separate threads... let me try to answer your original question.
On Thu, Apr 10, 2014 at 7:42 PM, Mark Hotchkiss <[email protected]> wrote: > Gentlemen: > > Is there some reason that you took over my thread on "Message Size > Limitations" and changed it to "Pluggable Transport Protocol" without anyone > referencing my issue? > > I guess I will re-submit my question under another thread to see if it might > get some attention. > > Mark > On Thursday, April 10, 2014 4:48 AM, Diego Duclos > <[email protected]> wrote: > 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 > > > > _______________________________________________ > 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
