[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] gpsd unnoticed of a remote IP gps brutally unplugged
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] gpsd unnoticed of a remote IP gps brutally unplugged |
Date: |
Wed, 8 Apr 2015 20:20:24 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Bruno Coudoin <address@hidden>:
>
> Hi,
>
> I am using gpsd with a remote TCP/IP gps serveur through 'gpsd://' (a
> CradlePoint IBR1100 router). In this case, if the remote gps is brutally
> unplugged from its power plug, gpsd stays unnoticed. It does try to
> reconnect but long after the gps server is back up (got a 5 hour
> occurrence).
>
> In the traces I have this error which shows the 5 hours delay:
> GPS on gpsd://192.168.0.1:8889 returned error -1 (16332.187656 sec since
> data)
>
> As it is, since we never talk to the device but only receive from it,
> and that the server cannot close or shutdown the socket, it is normal
> that at TCP level it goes unnoticed. One solution could be to add a TCP
> keepalive. Another option is to add a timeout when we don't get any
> traffic from a networked gps device.
>
> Am I doing something wrong, is there an option to handle that case?
>
> Bruno.
>
>
I don't understand what problem you are trying to solve.
GPSD is designed to recover from devices droping out and then returning.
In gpsd.c these definitions appear:
/*
* Timeout policy. We can't rely on clients closing connections
* correctly, so we need timeouts to tell us when it's OK to
* reclaim client fds. COMMAND_TIMEOUT fends off programs
* that open connections and just sit there, not issuing a WATCH or
* doing anything else that triggers a device assignment. Clients
* in watcher or raw mode that don't read their data will get dropped
* when throttled_write() fills up the outbound buffers and the
* NOREAD_TIMEOUT expires.
*
* RELEASE_TIMEOUT sets the amount of time we hold a device
* open after the last subscriber closes it; this is nonzero so a
* client that does open/query/close will have time to come back and
* do another single-shot query, if it wants to, before the device is
* actually closed. The reason this matters is because some Bluetooth
* GPSes not only shut down the GPS receiver on close to save battery
* power, they actually shut down the Bluetooth RF stage as well and
* only re-wake it periodically to see if an attempt to raise the
* device is in progress. The result is that if you close the device
* when it's powered up, a re-open can fail with EIO and needs to be
* tried repeatedly. Better to avoid this...
*
* DEVICE_REAWAKE says how long to wait before repolling after a zero-length
* read. It's there so we avoid spinning forever on an EOF condition.
*
* DEVICE_RECONNECT sets interval on retries when (re)connecting to
* a device.
*/
#define COMMAND_TIMEOUT 60*15
#define NOREAD_TIMEOUT 60*3
#define RELEASE_TIMEOUT 60
#define DEVICE_REAWAKE 0.01
#define DEVICE_RECONNECT 2
Is your issue that your local GPSD is waiting too long to try to reconnect with
the remote? Be aware that this won;t happen at all unless someone is
subscribed to the remote, eg. actually has a client session open.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>