[zeromq-dev] ØMQ over SCTP repository

[Michael Holmwood]

OK Pieter your strategy sounds good, I will aim for that. However, I have
TCP up and running with the pluggable mod already. I fixed my problem
regarding the deletion of the object - just created a cheap smart(?)
pointer with a mutex. All of the zmq tests are passing :-) Will have to
check it with all of the tutorial code to be sure, plus hammer it to death
with some sort of heavy load. For this to be fully complete I have to move
all of the options for TCP a dedicated options class - will look at doing
that shortly.

Mike.


On Fri, Jul 25, 2014 at 9:13 PM, Pieter Hintjens <ph at imatix.com> wrote:

> Hi Mike,
>
> My strategy would be to make a minimal plausible framework that does
> what you need for UDT, then we can try backporting existing transports
> (TCP perhaps) to that, and mature it over time. I'd like to try a
> semi-reliable UDP transport, for instance.
>
> -Pieter
>
> On Thu, Jul 24, 2014 at 7:24 PM, Michael Holmwood <mholmwood at gmail.com>
> wrote:
> > Hi all,
> >
> > OK so I am back onto the pluggable protocols for zmq. I created a new
> > repository: https://github.com/malloc-free/libzmq, and am in the
> process of
> > migrating code from the old (the hard way).
> >
> > One thing I am stuck on - I am not sure that the design I am using is the
> > best. I decided to use an interface because classes implementing that
> > interface could hold some state. I am not so sure that is really
> necessary
> > now. I think just using a dispatch pattern (at least I think that is
> what is
> > called) with pointers to network functions may be the better way to go.
> This
> > struct can easily be copied amongst the objects that need it without too
> > much drama. This also will help alleviate the other problem I am having -
> > deletion of the object used to access those functions. The way it works
> at
> > the moment is that it is shared across a few classes (tcp_listener,
> > session_base, stream_engine) and deleting it without causing problems
> seems
> > to be an issue. It may be that I need to look harder at zmq to work this
> > out. It may also depend on how the polling mechanism for new transports
> is
> > added. AFAIK application layer protocols can't use any of the kernel
> based
> > polling mechanisms, so I will need to look at a way to obtain and set a
> user
> > defined poller class - probably using a factory method and a setter in
> > io_thread. SCTP, for example, does not provide separate file descriptors
> for
> > streams - only for associations. UDT provides access to a polling
> mechanism
> > via its API.
> >
> > Regards,
> >
> > Mike Holmwood.
> >
> >
> > On Wed, Jun 25, 2014 at 2:17 AM, Pieter Hintjens <ph at imatix.com> wrote:
> >>
> >> Hi Michael,
> >>
> >> This is rather nice, and I like the promise of a pluggable protocol
> >> interface. What would it take to merge this back into libzmq master so
> >> that we can provide users with a single library?
> >>
> >> In terms of wrapping:
> >>
> >> - test cases in tests/
> >> - a zmq_sctp man page
> >> - further support via articles & examples
> >>
> >> A full fork of libzmq is unfortunate and probably not ideal,
> >> especially as you've done work we can use for other transports.
> >>
> >> -Pieter
> >>
> >>
> >> On Thu, Jun 19, 2014 at 4:40 AM, Michael Holmwood <mholmwood at gmail.com>
> >> wrote:
> >> > Greetings All,
> >> >
> >> > I have put our code for the addition of SCTP up onto a public
> >> > repository.
> >> > Please feel free to have a look, any comments would be much
> appreciated.
> >> > Please note that it is not finished, there are still some print
> >> > statements
> >> > (and commented out code) where I was tracking a problem in the code.
> >> > This
> >> > should be removed by tomorrow. The design partially incorporates our
> >> > idea
> >> > for a pluggable protocol interface. I have also added a function to
> the
> >> > zmq.h file that should probably be removed. Finally, the
> sctp_transport
> >> > class is far from complete - I am in the process of creating a
> >> > stand-alone
> >> > library that creates separate socket descriptors for streams on an
> >> > association - the current SCTP library for Linux does not provide
> this.
> >> > Also
> >> > there is no support for ØMQ over SCTP for Windows.
> >> >
> >> > https://github.com/malloc-free/zmq_over_sctp
> >> >
> >> > Repositories for the multi-streaming library, acceptance tests for ØMQ
> >> > over
> >> > SCTP, and guide code modified to use SCTP will be up shortly.
> >> >
> >> > Best 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
> >
> _______________________________________________
> 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/20140726/9cf466f2/attachment.htm>