Re: [gpsd-dev] Fw: Re: Virtual devices (as a solution to multiple sources location)

[Olivier Cornu]

On Thu, Jul 12, 2012 at 7:42 PM, address@hidden
<address@hidden> wrote:
> The intermediate daemon has to collect the data from the position sources,
> merge them into one position, and forward them to the second gpsd.
>
> In a system with separate links, i would connect all the other (non position) 
> sensors to the second gpsd.
> In my opinion, the intermediate daemon should simply forward all non position 
> data.

I think i get it now. You would do this:

    Location sensors                    Other sensors
         ↓↓↓↓                               ↓↓↓↓
         Gpsd(1) → Locations_mixer_daemon → Gpsd(2) → Client_app

But as NMEA2000 setups usually have a single physical link, what you
end up with is:

    All NMEA2000 sensors
            ↓
          Gpsd → Location_mixer_daemon → Client_app

… which supposes the mixer daemon proxies non-location events. Is that it?

If the mixer layer is a daemon, it will proxy all location events too:
we just need to *add* streams (like best guess location), not remove
any.
In fact, it's mainly going to be a proxy for gpsd events:
 1. It will run on port 2947 and use a slave gpsd instance on another
port, as Eric suggested
 2. It will speak the gpsd protocol, because that's what client speak
and expect from port 2947
 3. It will have to proxy all original gpsd events (TPV, SKY…) because
clients of port 2947 may very well require them
 4. It will also have to proxy some client requests targeted at the
gpsd instance (?WATCH, etc)
 6. Most likely, its only source will ever be gpsd: event sources
should be integrated at the multiplexer level anyway

But it will also have to duplicate lots of gpsd features:
 7. It will have to count clients and connect to the slave gpsd only
if at least one client is connected (in fact, the similar gpsd code
probably becomes irrelevant, as a gpsd process could be summoned when
needed and killed when not in use)
 8. It will have to duplicate the subscribers/dispatching code in
order to broadcast the relevant stuff to the right listener, as it
would become the /de facto/ "outgoing multiplexer" (only one client
connection to the "incoming multiplexer" slave gpsd instance), making
similar gpsd code useless

And most likely more…
Overall, it will burn a lot of resources just pretending it is gpsd.
In fact, *most* of its runtime resources will be spent in
gpsd-duplicated code, pretending it's gpsd. It's a high price to pay
for (supposedly) a UNIX inspired architecture purity, with few
practical cases -- if any -- to legitimate the cost.
So, to save on these new costs, it would probably end up linking
dynamically with the slave gpsd code (instead of using a socket).

What this tells me is that perhaps multiplexing and mixing are too
close to be stretched in two daemons. It's like putting a firewall and
a switch/router in the same box: it makes sense. If gpsd handles both,
it becomes possible to pile gpsd intances up like Lego blocks.
For example, your initial scheme would become:

    Location sensors   Other sensors
          ↓↓↓↓            ↓↓↓↓
          Gpsd(1)    →    Gpsd(2)   →   Client_app

This is the kind of architectural quality i like. :-)


Regards,

--
Olivier Cornu