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

Brian Adamson brian.adamson at nrl.navy.mil
Tue Mar 18 03:31:32 CET 2014


Hello,

The subject issue is still an outstanding one for the newly introduce "norm_engine" code to build/work.  Does anyone have an objection to reinstatement of the "encoder_base::has_data()" method or a suggestion for an alternative means to detect when an encoder has reached end of output for the current loaded message?  I understand that encode() returns zero when there is no more data but that doesn't lends itself to as clean an approach.  

The proposed method would be reinstated in the same form as it was in the libzmq-4.0.3 code as:

bool has_data() {return (to_write > 0);}


best regards,

Brian

On Mar 14, 2014, at 6:43 PM, Brian Adamson <Brian.Adamson at nrl.navy.mil> wrote:

> Hello,
> 
> 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/20140317/aa39f6ec/attachment.htm>


More information about the zeromq-dev mailing list