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 <[email protected]> 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
> [email protected]
>
>
>
>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
