[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request"
From: |
Gary E. Miller |
Subject: |
Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request" |
Date: |
Thu, 7 Sep 2017 13:16:50 -0700 |
Yo Florian!
On Thu, 7 Sep 2017 10:04:11 +0200
Florian Petry <address@hidden> wrote:
> Is it still planned to merge this fix? We are running into the
> "Unrecognized request" problem frequently when connecting one gpsd to
> another with gpsd://...
What fix? I see no fix. I also see no way, in this email, to
reproduce the problem. Please file an issue:
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
address@hidden Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
>
> Regards
>
> Am 28.06.2017 um 21:18 schrieb Larry Boyd:
> > This is a better fix for the server side.
> > The difference is that this one will give up after 10 seconds
> > rather than getting stuck forever.
> >
> > Although this is unlikely to make anything worse (unlike previous
> > version), I'm not sure that it is optimal, and frankly, I don't
> > understand the use of the protocol well enough (yet) to decide how
> > it should be adjusted, if at all.
> > For instance, I am using the number of bytes read as the mechanism
> > for determining if the entire request has been read, and I'm using
> > 1 byte as the threshold. What happens if the request is 100 bytes
> > long and we read 17 bytes? How can we tell that we have read to the
> > end of the entire request? Does a request always terminate with
> > '\r' or '\r\n'? I'm not sure if it does or not, and frankly, it may
> > depend on the implementation of the client. The two lines
> > immediately following the bulk of this patch suggest that requests
> > may not always end in '\n'.
> >
> > If someone can say for certain that a request will *always* have a
> > '\r' in the last or second-to-last byte, then ideally, we could
> > read until we find that byte, and then continue.
> >
>
> —
>
> ingenieur
> wissenschaften
> htw saar
>
> Hochschule für Technik und Wirtschaft des Saarlandes
> University of Applied Sciences
>
> Fakultät für Ingenieurwissenschaften
> School of Engineering
>
> Florian Petry, M.Sc.
> Forschungsgruppe Verkehrstelematik (FGVT)
>
> InnovationsCampus Saar
> Altenkesseler Strasse 17/D2
> 66115 Saarbruecken
> Germany
>
> +49 681 5867-648
> address@hidden
> http://www.htwsaar.de
> https://fgvt.htwsaar.de
>
>
>
pgp3QJOfe0WoJ.pgp
Description: OpenPGP digital signature
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Florian Petry, 2017/09/07
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Florian Petry, 2017/09/07
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Eric S. Raymond, 2017/09/07
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request",
Gary E. Miller <=
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Florian Petry, 2017/09/08
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Gary E. Miller, 2017/09/08
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Gary E. Miller, 2017/09/08
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Florian Petry, 2017/09/11
- Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request", Gary E. Miller, 2017/09/11