[zeromq-dev] Pluggable Transport Protocol

[Mark Hotchkiss]

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 <diego.duclos at palmstonegames.com> 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 <ph at imatix.com> 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 <mholmwood at gmail.com> 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
>> 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
>


_______________________________________________
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/20140410/32ad4742/attachment.htm>