Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-api should broadcast it's capabilities for clients #205

Open
fnoop opened this issue Feb 2, 2020 · 4 comments
Open

-api should broadcast it's capabilities for clients #205

fnoop opened this issue Feb 2, 2020 · 4 comments
Assignees
Milestone

Comments

@fnoop
Copy link
Member

fnoop commented Feb 2, 2020

Related to #204 - should -api send it's current modules/capabilities so that clients will know what they can/can't request?
For example, if -api doesn't have access to (currently) mavros, then it can't send mavlink/mavros data. The client should then know that so it doesn't request it. But (base) maverick data should still be available at all times, so it should be able to send/request that.

@SamuelDudley SamuelDudley self-assigned this Feb 5, 2020
@SamuelDudley SamuelDudley added this to the 1.2 milestone Feb 5, 2020
@SamuelDudley
Copy link
Member

@fnoop this is possible via a schema introspection request from the client, which provides the client with the full schema / what it can request.
I will add loaded modules to the status.

@SamuelDudley SamuelDudley changed the title Should -api broadcast it's capabilities for clients? -api should broadcast it's capabilities for clients Feb 26, 2020
@SamuelDudley
Copy link
Member

Advertise loaded modules and notify changes to schema

@fnoop
Copy link
Member Author

fnoop commented Feb 29, 2020

Client work tracked in goodrobots/maverick-web#151

@fnoop
Copy link
Member Author

fnoop commented Mar 3, 2020

We could add an -api parameter to choose which kind of zeroconf to use - either an existing zeroconf service or start a fresh one. So if there's an existing avahi/whatever running on the system we can register with that, otherwise we can start a new service.
It looks like python-zeroconf starts a new service (which clashes with avahi) and won't co-exist.
https://github.com/jstasiak/python-zeroconf

We can add services to avahi either by placing an xml definition in /etc/avahi/services, or (better) by communicating with it over dbus:
https://github.com/lathiat/avahi/tree/master/avahi-python
https://stackoverflow.com/questions/3430245/how-to-develop-an-avahi-client-server
https://en.wikipedia.org/wiki/Zero-configuration_networking

python-zeroconf and avahi both listen on udp port 5353 to respond to mdns requests over multicast. We (-api) don't actually want to serve mdns, but rather just the service discovery portion (and just a single entry at that). So logically we don't want to run zeroconf through -api unless we absolutely have to, rather just register a service with an existing zeroconf service.

It might be easier to just have avahi as a zeroconf dependency for -api, and just add support to register a new service with avahi?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants