Sending an "empty" FDT Instance violates the FLUTE specification

[rjb1000]

Context

The current behaviour of the rt-libflute reference implementation of FLUTE periodically sends an "empty" FDT Instance when there are no objects transmitted in the FLUTE session:

<FDTInstance ...></FDTInstance>

Some FLUTE receiver implementations may be relying on this behaviour as a "keep-alive" for the FLUTE session.

Description of bug

According to section 3.2 of RFC 3926:

Within the file delivery session the FDT is delivered as FDT Instances. An FDT Instance contains one or more file description entries of the FDT. Any FDT Instance can be equal to, a subset of, a superset of, or complement any other FDT Instance. A certain FDT Instance may be repeated several times during a session, even after subsequent FDT Instances (with higher FDT Instance ID numbers) have been transmitted. Each FDT Instance contains at least a single file description entry and at most the complete FDT of the file delivery session.

This means that the current practice of signalling an "empty" FDT Instance when there are no objects being transmitted is incorrect. No packets should be sent in this case, and it should not be used to signal "keep-alive" for the FLUTE session.

[rjb1000]

@davidjwbbc: This bug hasn't bee addressed yet?

[davidjwbbc]

I need to look at rt-libflute and work out the best way of achieving this.

[dsilhavy]

@rjb1000 @davidjwbbc : Is the idea to simply avoid sending empty FDT instances? Or should this behavior be replaced with a different/modified approach?

I can probably look into this and as a first step simply avoid sending the empty FDT instances.

[rjb1000]

@rjb1000 @davidjwbbc : Is the idea to simply avoid sending empty FDT instances? Or should this behavior be replaced with a different/modified approach?

@dsilhavy: We're hoping that it can be as simple as not sending empty FDT instances when there are no objects being transmitted in the FLUTE session. @davidjwbbc is looking into whether it's as simple as putting an if statement at a strategic point in the code, or whether it's more complicated than that.

More broadly, we also want to consider this holistically with the enhancement to rt-libflute described in #47.

[davidjwbbc]

I have this working in my development branch. Tested with the example programs and the MBSTF.