[zeromq-dev] encoder::has_data() method deprecated?

Brian Adamson brian.adamson at nrl.navy.mil
Fri Mar 14 23:43:54 CET 2014


I had ported our NACK-Oriented Reliable Multicast (NORM, RFC 5740) protocol implementation into a copy of the libzmq 4.0.3 source tree and it working with some test code implemented with the "pyzmq" API.   However, in the past couple of days, using the latest code from GitHub in order to provide a candidate submission of this capability, I found that the "encoder::has_data()" method was no longer available.  It had been used in the "stream_engine" code and I was using it in my "norm_engine" code. 

 I used it because NORM has a mechanism for marking application-defined message boundaries so that late-joining receivers can easily "synchronize" to sender transmission streams and recover application-defined message boundaries.  So I used the "encoder::has_data()" to know when the last byte of the message had been "encoded" and written to the NORM transmit stream for the NormStreamMarkEom() function to be applied that invokes the message boundary capability.  

I started to implement a work-around based on the "msg::size()" and counting bytes written to the stream, but that means knowing/determining the encoder overhead (i.e. flags, length fields, etc) and I want to be more forward-looking than that since the NORM transport can potentially be applied to more ZeroMQ socket types and purposes than what I've done so far.

So, my question is if I should re-implement the encoder::has_data() method or if there is a better approach.  In my fork, I've done this and verified that the "norm_engine" works as it did with the libzmq 4.0.3 code, but Pieter has wisely suggested I put this question to the list.

Also, I have a short overview/write-up of what I've done with ZeroMQ/NORM that I can post to the list if there's interest? And about as soon as this issue can be resolved, I can issue a pull request for this "norm_engine" code as well. 

best regards,

Brian Adamson
brian.adamson at nrl.navy.mil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140314/5a43522c/attachment.htm>

More information about the zeromq-dev mailing list