SF: PC: Spurious CFDP transaction finished event when sending a batch of files

[iondev33]

I am using an updated version of cfdp_test to send a batch of files from one node to another. I am using cfdplisten to monitor the cfdp events on the receiving node. When multiple files are sent, older 'transaction finished' events seem to be generated once in a while a bit later. In attached log file, from Transaction ID: 1.30, transaction finished event is first generated at: 2021-02-18T21:35:00.668. Another similar event is generated again at 2021-02-18T21:35:05.421. You will need to ignore the cfdpFileName which is captured from last metadata received event.
It is also not clear why the EOF received event for transaction 1.30 is printed at 2021-02-18T21:35:01.078 after transaction finished is printed at 2021-02-18T21:35:00.668. Are the event orders not preserved?
This is a little confusing. Thanks.

------ comment --------
I am looking into this a little more. I am currently using a simple cfdp command file like this:

d {nodeNumber} f {sourceName} t {destName} &

So this would use a default mode 0, criticality 0, closure latency 0???, It is possible that some packets get dropped... not sure why transaction finished event would get out of order (which is bad since I need to match it with info in metadata).
May be I can try with additional parameters to get to a reliable file transfer?
like:
a 60
m 2
c 1

Is there a recommendation for CFDP file transfers?

--------comment---------
When the file already exists on remote system, the behavior becomes problematic with weird events being generated out of order and duplicated. When the file does not exist, behavior seems to be as advertised in all modes. This was troubleshooted by adding fileStatus and deliveryCode in print statements of cfdp_listen.

-------comment----------
After a weekend of testing, CFDP batch transfers are still problematic. Events do not seem to be caught (or generated) in order. Transfer finished may occur before the metadata event. In mode 0, the metadata event can even be missing. In mode 2, with version 3.7.2, it is not working with more than one file transfer

-------comment----------
In ION, CFDP events are delivered to the CFDP user application program in the order in which they are detected. But we don't want a stuck CFDP user application program to torpedo the whole node, letting unlimited growth in the queue of unhandled events consume all resources in the system. So the length of the CFDP queue of not-yet-handled events is limited, and when appending an event to the queue causes that limit to be exceeded the oldest events in the queue are deleted, in order, until the queue length is again within its limit. The limit defaults to 20 but you can change it in cfdpadmin by using the "m maxevents" command (see the cfdprc(5) man page).