Feature request: support for --net-heartbeat <secs>

[kx1t]

In areas with low UAT traffic, the data stream dump978 (raw) -> uat2esnt -> readsb will disconnect when there's no traffic after a while. This is causing a lot of connects / disconnects that are visible in the logs.

Would it be possible to add a heartbeat option that keeps the data connection open? Ideally, this would be exposed through a command line option like --net-heartbeat <secs>, where the heartbeat is off if this is not included on the command line.

Tnx!

[mutability]

Which connection is disconnecting?

[YipYup]

I'm not any expert by any means, and perhaps kx1t can help clarify, but here's the issue I logged on the downstream project.

sdr-enthusiasts/docker-dump978#65

[mutability]

The reason that I ask is that

a) I'm not clear how exactly your pipeline is working (legacy uat2esnt operates as a pipe, how are you turning that into network connections);
b) if it's the uat2esnt -> readsb connection that is reconnecting, then that's where the heartbeat needs to be, i.e. dump978 changes wouldn't do anything

[kx1t]

Sorry for the delay… the reason is that we upgraded our pipeline (took bit of time) and that we are now connecting straight from dump978 using that program’s raw output to Wiedehopf’s branch of readsb using the (new) uat_in net-connector option of that branch of readsb. No more uat2esnt. Works great, except for the connection time-outs in no-traffic hours :)

So the heartbeat should be implemented in dump978.

[mutability]

Okay. What's your proposed message format for a heartbeat (readsb will obviously need to handle this too)

[kx1t]

the same message format that is used in W's readsb fork -- see https://github.com/search?q=repo%3Awiedehopf%2Freadsb%20heartbeat&type=code

(I think the message format is here: https://github.com/wiedehopf/readsb/blob/c4a0e401d12b7e0c545eee20794abf940b5893bd/net_io.c#L105-L107 but the rest of the search shows you how it's implemented in readsb)

Thanks :)

[mutability]

Those heartbeats are for other protocols - AVR, Beast, SBS. They won't directly work with the dump978 raw-UAT format.

I could just pick something, but then readsb would likely break when it hears it. This needs coordination between the two ends to agree on what the heartbeat should look like.

[kx1t]

eh... line 106...

static const char raw_heartbeat_msg[] = "*0000;\n";

Isn't that for raw?

[mutability]

That is the AVR-style "raw" connection for 1090MHz data: https://github.com/wiedehopf/readsb/blob/c4a0e401d12b7e0c545eee20794abf940b5893bd/net_io.c#L947

UAT is here (note "no_heartbeat" currently, but that's actually a red herring anyway since IIRC it is output-side-only):
https://github.com/wiedehopf/readsb/blob/c4a0e401d12b7e0c545eee20794abf940b5893bd/net_io.c#L964

[wiedehopf]

readsb has the same code as uat2esnt ;)

Pretty sure nothing will break readsb and i can implement whatever you think is best.

[wiedehopf]

In doubt just propose something here and i'll look at the readsb code ... or maybe upload a sample output from the network and i can feed it in with socat and test.