Connect API v2 manifest response question

All …

I’ve got a fairly specific question around retrieving the manifest from the Connect v2 API.

In some testing against several different IF devices, the start of my manifest data looks like this:

ff ff ff ff c0 ad 00 00 bc ad 00 00 38 39 31 2c 33 2c 69 6e 66 69 ...

If I break this down:

ff ff ff ff: This is -1 being returned to indicate this is a response to the manifest request per the documentation

c0 ad 00 00: Based on the documentation, I would assume this indicates the length of the manifest data; in this case the value is 44480 (but, as we will see later, this might not be the actual length)

bc ad 00 00: This is a series of four bytes (an Int32, presumably?) which appears to be consistently an integer value 4 less than the previous integer above (in this case, 44476)

The documentation says the manifest:

… will return the ID you sent ( -1 ), and the length of the data you are about to receive in bytes as an integer … [and] Following the ID and length , the manifest is represented as a (very long) string.

I am unsure why there appear to be three integers prior to the actual manifest data starting from the 12th byte in the data.

If I treat everything from the 12th byte onward as the manifest everything looks right:

515,2,aircraft/0/systems/nav_sources/adf/2/distance_to_glide_path
782,3,infiniteflight/cameras/2/z_angle
804,3,infiniteflight/cameras/4/x_angle
...

(As an aside, if I treat bytes 8 onwards as the manifest then the first entry in the manifest has an invalid command number.)

So – how do I interpret these two bytes after the -1? If I look at the total data length I get back in this example I get back 44488 bytes including the first 12 bytes discussed above which would imply the length of the manifest itself is 44476.

In that case, it implies the manifest length is the third integer in the buffer. So, then, what’s that second integer (44480)?

Any insight on this much appreciated. While I seem to be successful processing and using the manifest I don’t feel fully comfortable not knowing what each piece of the data means. Something is missing for me.

As I reread my post a light bulb went off.

If I consider the fact that the data returned is -1 followed by the length of data that will be returned followed by a “(very long) string”, does that mean the “(very long) string” is actually an integer indicating the length of the string followed by the string itself rather than simply a string?

That might explain why the two bytes have a difference of 4. Can someone confirm this?

(and, if this is case, maybe the documentation could be updated to clarify this as I had initially interpreted the document to mean the -1 is followed by one integer and then the actual string itself.

This is correct :)

In the documentation for how a string is sent, it should specify that all string responses contain a leading int that specifies their length.

I get it now but I think that’s where I feel the documentation is unclear. I would have initially interpreted the docs as saying that the first byte after -1 is the leading int specifying the length of the string.

But on rereading now it can also be interpreted as saying that byte after the -1 is the length of the data to follow which itself is another integer (to specify string length) followed by a string.

I think it is a bit ambiguous.

Who maintains the documentation so I could perhaps make this suggestion?

Can and Kai I believe, they’ll see this :)

2 Likes