FYI: new dnstap implementation won't work with libfstrm

[fhriley]

The new implementation of dnstap sends a unidirectional stream over sockets. Both the libfstrm and golang-dns clients will fail to decode this stream because they are hardcoded to expect a bidirectional stream when using sockets (both unix and tcp). I view this as a bug in the clients, but I thought I would give you guys a heads up. Both of those projects appear to be dormant.

[edmonds]

The unidirectional Frame Streams transport was designed to be written out to files (because there is no protocol peer when writing to a file), while the bidirectional transport was designed for sockets. The reason for using the bidirectional transport on sockets is to ensure that both sides of the connection are using the Frame Streams protocol before streaming a potentially large amount of data over the socket and automatically reconnecting when the connection is broken.

This diagram shows the relationship between the two transports:

[fhriley]

Ah, ok, then it would be a bug in unbound. I was using master here because it has the fix for #193, which I needed. I assume the code here has the same issue. I tracked it down to the code not sending the READY control. It was only sending START.

[ralphdolmans]

Thanks both for reporting this issue and providing information! The changes in PR #264 make the Unbound frame streams implementation bidirectional.