Hi Brian, Nice work. No problem introducing has_data member function. Another option, I think, would be to rely on the fact that encode member function returns 0 when there are no data pending in the encoder.
- Martin On Fri, Mar 14, 2014 at 11: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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
