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

[Eric S. Raymond]

Third in a trilogy of old bugs I don't have time to fix because of NTPsec.
Did this ever get addressed?  If not, I'd appreciate it if one of the
regulars would step up.  You'd help two projects - GPSD by fixing it,
and NTPsec by taking a weight off my mind.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
> --- Begin Message ---
>
>
>
> Subject: 
>
> [gpsd-users] tcp://feed failure strategy
>
>
>
>
> Date: 
>
> Wed, 6 Apr 2016 10:35:03 +0200
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101	Thunderbird/38.7.0
>
>
>
>
> 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
>
>
>
> --- End Message ---