[Discuss-gnuradio] Getting consistent noutput_items

[Mike Rex]

I am having a problem adapting a UDP sink block for sending raw protocol 
frames. I am using a 32KB binary file source connected to my Sink 
connecting to my Source on another PC, finally outputting to a file 
sink.  My expectation/goal is that my output file is identical to the 
input file so that nothing is lost or added to the data.

When I use a 32KB input file and using byte data size, the noitems are 
32768 and I divide that down into 4 equal 8192 packets with 32 bytes 
frame overhead. I can do this and get the 4 expected packets received 
and file output matches input file.

However, when I go to 64KB input file, the expectation is simply for it 
to send 8 packets of same size.  However, my initial debug is showing 
entering the sink block 3 times instead of twice; getting noitems values 
of 32768, 32767, and 1.  What this means, is my 8th packet is missing 
the very last byte, and a 9th packet is sent with the final byte plus 27 
bytes padding, which means the resultant file is short by a byte, or 
long by the padding.

noutput_items (dec): 32768
d_block_size (dec): 1
pay_len (dec): 8192
numPackets: 4
lastPayloadSize (dec): 0

noutput_items (dec): 32767
d_block_size (dec): 1
numPackets: 4
lastPayloadSize (dec): 8191

noutput_items (dec): 1
d_block_size (dec): 1
numPackets: 1
lastPayloadSize (dec): 1


When using complex, then 8 bytes are pushed into a 9th packet, so 
remainder bytes change with the itemsize.  Is there something I can do 
to make noutput_items consistently be 32768, or will I need to find a 
workaround to preventing/stripping the padding on the receiver side?  
I'm pretty sure the intended user will need to be able to input files 
larger than 32KB.

noutput_items (dec): 4096
d_block_size (dec): 8
numPackets: 4
lastPayloadSize (dec): 0

noutput_items (dec): 4095
d_block_size (dec): 8
numPackets: 4
lastPayloadSize (dec): 8184

noi (dec): 8
noutput_items (dec): 1
d_block_size (dec): 8
numPackets: 1
lastPayloadSize (dec): 8

Is this related to noutput_items being an int?  I wouldn't expect it to 
be an issue at 65535.  Is there anything I can do to get a consistent or 
even number of noutput_items? Not sure what my best work around options 
are, but getting noutput_items of 32768 consistently sure would make my 
life easier. I thought I just needed to make the input file a multiple 
of 32 bytes to ensure I'm not needing to pad the final packet, but 64KB 
is a multiple of 32 and has this dangling data issue.  I believe the 
user will be inputting both a file source (with/without repeat) and 
later streaming to it.  This might not be an issue for streaming, but I 
do believe this will be an issue for file sources.

Thanks in advance for any ideas or solutions.
Mike