[gpsd-users] tcp://feed failure strategy

[Fulup Ar Foll]

I'm using GPSd as a concentration HUB for AIS targets coming from 
multiple sources. Unfortunately GPSd logic when TCP:// input feed fails 
is far from optimal and not adapted to support long term TCP connections.

* PROBLEMATIC: An AIS hub should remain open 7/7days & 24h/day. In 
theory (at least) it should never stop and the goal it to never have to 
restart any of your GPSd services. As a result channels from either your 
fix AIS station or your external feed (ie: AIShub) could have to remain 
open for months. Now when you open a remote TCP link for months, at some 
point in time your TCP channel will break. It is just a matter of 
waiting long enough for this to happen.
* ISSUE: In previous GPSd version, when one single TCP feed breaks Gpsd 
kill itself (hoops!!!). In latest version (3.16) it even worse has it 
remove the link without ever trying to reconnect onto it.

The old model was hugely, but somehow easy to handle. We had to create a 
small monitoring script to check if GPSd was still responding, when not 
it had to be restarted. With new model it is much harder has your GPSd 
still respond but may have disconnected from your TCP:// feed.

Turn around, not really optimal but at least it works. Use 'socat' to 
proxy TCP feeds into UDP before re-injecting them to GPSd.

WANTED SOLUTION: to keep GPSd running for ever, we would like an 
automatic reconnection on TCP:// feeds. Something equivalent to what I 
coded into GPS2udp, where input channel is monitored and in case of no 
respond for more than XXseconds the channel is close en reopen.

Other bug on TCP: I also noted that is a feed block (connection 
initialise but listen does not respond) then GPSd freeze for ever (noted 
on 3.11 and 3.16). This error case is rare and probably not critical, 
but at least an error message would be welcome.

Fulup