This is adapted from the FlightAware fork, with some cleanup and
modifications needed to work with the net-cleanup changes.
Inclusion of "verbatim" TSV data read from an AVR-format input
connection is not supported.
Pull #54 breaks the Windows version of dump1090 due to a bug in the
inet_aton() windows function.
1) Fix the bug in the windows inet_aton()
2) Modify the command line code to strdup() the command line string.
3) Leave the Modes.net_bind_address pointer NULL if no command line
specified
Pull #54 permits changing the default bind address. The default was
127.0.0.1. This prevents external access unless a command line switch is
used. Since many users of dump1090 are using dump1090 as remote receiver
heads for programs such as plane plotter, this is undesirable. If you
want to lock down your RPi for local use only then use the command line
switch. If not, retain legacy open mode by binding to 0.0.0.0 by
default.
Mostly refactoring the common code that was duplicated
between the different output types so that there aren't
many copies floating around.
This introduces "struct net_writer" to store the state of a
particular type of output service - buffers, time of last write,
connection count etc. prepareWrite() / completeWrite() give access
to the buffer and handle the actual writes and flushing when needed.
Heartbeat and time-based flushing move into a generic periodic-work
function.
Update the SBS output code to use the new infrastructure. This makes
a big different to CPU use when under load.
When we read from some client A, we may end up forwarding a message to other
clients. If we forward to some client B and there is a write error, then
we close B and remove it from the client list. However, if before this happened
A->next == B, then the read loop will still be holding on to a pointer to B,
and we crash.
As it's unpredictable what clients could be closed at what point, the simplest
approach is to retain closed clients in the list until we are at a point where
we know there are no stray pointers on stack, and only then modify the list.
This also simplifies anything that has to loop over clients, as it doesn't need
to worry about the current client being freed under it.
If we demodulate a message in 2.4MHz mode and it has a bad, uncorrectable CRC,
and --phase-enhance is on, then retry with the other possible phases until
we get a good CRC or run out of phases to try.
This is very expensive in AGC mode (lots of candidates that are not real
messages) but relatively cheap otherwise. It yields another 10% messages.
Also factor out some common stats code to avoid lots more copy/paste.
There is a danger in always using relative decoding where possible.
If there is an undetected error in the first pair of messages received,
then global CPR decoding will give a bad position, and subsequent
relative decoding will just walk around near that bad position even
though many error-free pairs of odd/even messages may have been received.
The first pair of position messages also tends to be the most error-prone, as
they are usually received at the extreme edge of receiver range.
(I see this happen at least once a day in practice)
So, instead, prefer to use global decoding when we have sufficiently recent data.
With recent data this should always be as good as relative decoding, and it
avoids getting stuck with bad data for long periods of time. If we don't have
enough recent data for a global solution, fall back to relative decoding.
This disables most decoding of the contents of Mode S messages, aircraft tracking, and some output modes that depend on them.
It's intended for edge receivers that just forward to a central hub rather than processing data locally.
