[CLOSED] 3. Orchestrator needs to get device descriptions

[trkks]

Author  'juaatark'
Created 2023-01-11T17:05:37.545+02:00
Updated 2023-03-01T13:53:42.403+02:00
Closed  2023-03-01T13:53:42.392+02:00

From idea-paper section 3.1:

After the orchestration server receives a new device introduction, the exploration phase begins; The orchestrator queries the capabilities of the device using REST with a well-known URI, and the device replies with an CoRE description

Which continues immediately:

For the applicable parts device description follows WoT-Thing description [3], and additional details of the device, such as which are needed for the deployment solution, follows the OpenAPI specification [1].

Needed:

• [x] Subroutine to query devices when exploration phase is initiated (iot-advert received -> event -> call subroutine?)
• [x] Saving queried info (initial version of WoT-TD and "hardware" info like memory and "computing power" ~CoRE description~) to device database

[trkks]

Author 'juaatark'
Originally created at 2023-01-18T10:31:00.469+02:00

Using library multicast-dns (see the packet format under "API"). I'm probably going to try running the "iot-device"-part in nodejs (instead of flask-demo) as well to test things out.

[trkks]

Author 'juaatark'
Originally created at 2023-01-18T12:10:26.488+02:00

Initial test implementation of mDNS communication working in 34ae6094b09d322c8f8ca8d1d1ac6644e01d0d26

[trkks]

Author 'juaatark'
Originally created at 2023-01-18T15:02:12.345+02:00

Toinen js-kirjasto on mdns-scanner.

[trkks]

[Sub discussion]
Author 'juaatark'
Originally created at 2023-01-18T15:05:06.546+02:00

Fiksumpi logiikka olisi luultavasti että, orkestraatiopalvelin etsii _webthing._tcp.local "ylä"-tyyppisiä IoT-laitteita. Tällöin tulisi vähemmän liikennettä verkkoon vrt. kaikki laitteet "etsivät" palvelinta.

[trkks]

Author 'juaatark'
Originally created at 2023-01-18T15:53:15.961+02:00

Based on this quote on a page about mDNS: https://www.ionos.com/digitalguide/server/know-how/multicast-dns/

-- the request [client's multicast searching a matching host] also goes to the group participant who owns the host name that is being searched for. The latter responds to the entire network (also via multicast). All participants are informed of the connection between the name and IP address, and can make a corresponding entry in their mDNS cache.

I thought that IoT-devices entering the network could advertise themselves to the orchestrator, and then all the other already connected ones could learn this new device's IP the same time, which is definitely good! I just understood the logic exactly the wrong way around :rolling_eyes:

[trkks]

[Sub discussion]
Author 'juaatark'
Originally created at 2023-01-18T15:59:29.530+02:00

Lisäksi IoT-laitteet vastatessaan orkin kyselyyn kertoisivat koko verkolle IP:nsä -> kaksinverroin hyötyä (uusi laite löytyy sekä orkin että verkon muiden IoT-laitteiden tietoon)

[trkks]

Author 'juaatark'
Originally created at 2023-01-19T15:43:03.231+02:00

This bonjour library seems promising as well, although it's not been maintained for years...

[trkks]

Author 'juaatark'
Originally created at 2023-01-23T17:00:01.654+02:00

Changed to use the bonjour-library instead (seems as user friendly as mdns-scanner but is more popular) and switched the logic where now devices advertise themselves as services (now the example is a HTTP-server) and orch finds them by scanning 719cbf57596f981ce6d05d4385f5dfa11f773f30

I give no promises on this here working outside localhost though.

[trkks]

[Sub discussion]
Author 'juaatark'
Originally created at 2023-01-26T14:44:10.562+02:00

Interaction working with at least two "different" simulated devices (where the other joins on its own) on network setup by docker compose 7bccad9b2d4911257ee5595eef9f0f9cecff5e5d.

[trkks]

Author 'juaatark'
Originally created at 2023-02-16T16:42:53.881+02:00

Implemented far enough at 3319a3b31a06314717da45166b75e555300207eb to justify closing this imo. Just reopen this or open new issue(s) for bugs/changes etc.

[trkks]

[Sub discussion]
Author 'juaatark'
Originally created at 2023-02-16T16:43:22.306+02:00

Why's this commit missing now :o?

[trkks]

Author 'juaatark'
Originally created at 2023-02-22T14:54:41.892+02:00

After discussion on 22.02.2023 it seems better if device descriptions are not the WoT format but our own definition that:

1. describes the platform,
2. tells what supervisor-functions are available (for Wasm-modules to call)

The WoT-TD would then be used for M2M communication/orchestration (correct me if I'm wrong!)

[trkks]

Author 'juaatark'
Originally created at 2023-02-22T18:19:36.258+02:00

Updated device-description schema to better match what was discussed in 88a79866d1448c90c3477b89c482d49727b2ae9f