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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >> > [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
