On Wed, Apr 17, 2013 at 02:09:26PM -0400, Sean Nowlan wrote: > Just thinking out loud: could this be worked into the tagged_stream_block > class? If mtu is left as a default, behavior will be identical to the way it's > defined now and work() will always get called with the exact number of items a > derived block wants. If a length tag comes along that is greater than the mtu, > it should shout its disapproval and/or truncate the packet and/or "fragment" > (though this introduces even more nightmares... what's next, fragment offset > tags?? actually, maybe...). However if mtu is defined to be bigger than > max_noutput_items/relative_rate, we should handle that case somehow.
Yep, it should go into gr_tagged_stream_block. Although as you say, it's a tricky call what happens in this case. But in the very least, it should be checked and fail--currently it would check and run indefinitely. M -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
pgpCIIPLK1NWf.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
