I considered using such a data structure, but the challenge there is that there's no guarantee of a 'file transfer complete' that could be used to trigger reassembly and adding to the export objects list. AFAIK, it's also not possible to have a function to run after all packets were dissected to generate the export object list entries then.
Moshe
On Tue, Dec 14, 2021 at 9:34 AM Moshe Kaplan <mosheekaplan@xxxxxxxxx> wrote:
>
> Good afternoon,
>
> I've been working on MR 1611 for exporting FTP objects. One of the complexities is that because the transmitted FTP files are spread across multiple "packets", they need to be reassembled by the export objects 'tap' into a single block of contiguous memory, so they can be exported. In the MR's current implementation, this is done by appending the data from each ftp-data packet as it is received.
>
> Martin Mathieson commented here:
> "I would still like to hear more opinions on whether we should export data that isn't re-ordered/reassembled. I've unfortunately missed the past couple of developer dens. Maybe ask on the dev list about whether it would be confuse people, and if it would, whether there are ideas on how to do it?"
>
> Does anyone have any suggestions as to how to best deal with the problem of reordered packets?
I suspect you are going to have to maintain a data structure that
allows you to reassemble them, but you probably knew that.
How about a data structure (perhaps a hash indexed by starting
sequence number) with the ending seq number or length and pointer to
the data and a more-data flag or something.
Then, when you have all the data you can index into the hash table by
starting sequence number starting at 1.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)