Comments (3)
I have traced down this problem to the line 36 in upnp.js:
client.on('response', (headers, statusCode, rinfo) => self.parseMessage(headers, statusCode, rinfo));
It seems that if there are many devices answering to a M-SEARCH, the processing in the discovery adapter takes too long, so that many responses are lost.
I have changed the line to
client.on('response', (headers, statusCode, rinfo) => setTimeout(() => self.parseMessage(headers, statusCode, rinfo), 3000));
so that processing the responses is delayed until all resonses should have arrived (the default maximum wait time MX in the node-ssdp is 3 secc).
With this modification, the detection works reliably.
I would like to issue the PR for the frontier-silicon.js detector module including this modification.
Btw: Since the purpose of the multicast-client is not clear to me, I did not modify the lines 35 and 37.
I guess the multicast-client is thought to catch advertise messages which are sent by ssdp servers from time to time or when they are entering the network.
But since the discovery adapter is not running permanently in the background and thus will not catch
any advertisements, I do not see much sense in the multicast-client.
From my understanding the second ssdp (multicast-) client is not necessary for the working of the upnp discovery and could safely be removed from upnp.js.
So if you are preparing a new release of the discovery adapter, please consider removing the multicast-client code from upnp.js.
from iobroker.discovery.
Copied answer (german) here from telegram:
Hhmm … sorry aber das macht irgendwie keinen Sinn. Der event wird getriggert mit einem Datenpaket und wenn mehrere kommen sollte einfach Event mehrfach getriggert werden. An sich ist JavaScript da schön asynchron - es seinen die Library limitiert das. Versuch mal ob ein „setImmediate“ oder ein timeout mit 0s auch schon geht.
Das was du gerade tust ist am Ende die Verarbeitung jedes einzelnen Pakets um 3s nach hinten zu verschieben. Das ist denke ich nicht was du wirklich willst. Die Daten werden an sich nicht magisch mehr nur weil es später verarbeitet wird.
from iobroker.discovery.
@Apollon77
Hallo Ingo, ich bin dafür, die Diskussion hier fortzusetzen, in Telegram verliert man leicht den "Faden".
Ich habe mal etwas mit den timeouts experimentiert:
Die Varianten mit „setImmediate“ oder timeout mit 0s habe ich probiert. Das führt dazu, das genau nach 15s der timeout der upnp methode zuschlägt. Bis dahin wurde aber nur ~ein Drittel (50) der responses verarbeitet und damit nicht alle Geräte gefunden.
Wenn ich den timeout der upnp methode auf 60s hochsetze, werden 160 responses empfangen und alle Geräte(11) erkannt. Ich vermute, dass die hohe Anzahl von responses durch zusätzlich empfangene ssdp:alive messages zustande kommt.
Wenn ich den timeout der upnp methode bei 15s belasse, aber den settimeout von 0 auf 3s erhöhe, so werden um die 130 responses empfangen und alle Geräte erkannt. Merkwürdigerweise wird in diesem Fall der Test nicht nach 15s abgebrochen sondern endet erst in ~35s. Wenn ich in diesem Fall den timeout der upnp methode auf 60s hochsetze, ändert sich nur die Anzahl der responses (vermutlich durch ssdp:alive messages), die Anzahl der gefundenen Geräte ändern sich nicht.
settimeouts unter 3s (z.B. 1s) führen zu weniger responses (113), kürzerer Dauer bis zum Ende der Discovery (31s) und es werden nicht alle Geräte erkannt.
settimeouts über 3s (z.B. 4s) führen zu kaum mehr responses (135), wenig längerer Dauer bis zum Ende der Discovery (37s) und es werden alle Geräte erkannt.
Aus diesem Verhalten habe ich geschlossen, dass ein settimout von 3s optimal ist. Ich habe mir das so erklärt: Die Verarbeitung der responses wird verzögert, bis alle responses eingetroffen sein sollten (die standardmäßige maximale Wartezeit MX im Node-SsDP beträgt 3 Sekunden). Die Variation der Anzahl der responses kommt vermutlich durch zusätzlich empfangene ssdp:alive messages. (die Notwendigkeit des Empfangs der advertisments habe ich ja schon oben infrage gestellt).
Nur als Anmerkung dazu - es gibt in meinem Netzwerk einen nicht normgerechten ssdp-Server (genauer ein SEMP Gateway, dass auf meinem ioBroker 192.168.1.154 läuft), der sich nur durch gelegentliche ssdp:alive messages bemerkbar macht. Auf M-SEARCH reagiert er nicht. Allerdings wäre das für mich kein Grund, den Empfangs der advertisments beizubehalten, denn es ist ja reiner Zufall, wenn sich das SEMP-Gateway während der Detektionsphase meldet.
Hast Du vielleicht eine andere Erklärung oder Sichtweise auf dieses issue?
Ich habe das etwas längliche logfile meiner Experimente mal angehängt, falls Du Lust hast meine o.g. findings nachzuvollziehen.
iobroker.2023-08-03.log.txt
from iobroker.discovery.
Related Issues (20)
- Update stable version in repo from 2.7.0 to 2.7.3
- Update stable version in repo from 2.7.3 to 2.7.5
- Adding support for openknx HOT 6
- Adding support for e3dc-rscp HOT 6
- Think about to fix the issues found by adapter checker HOT 1
- Compatibility check to js-controller 4.0 HOT 1
- Update stable version in repo from 2.7.5 to 2.8.0
- Text der Einstellungen im dunklen Farbmodus nicht lesbar HOT 2
- Expert Mode for Network Seqments HOT 2
- Update stable version in repo from 2.8.0 to 3.0.3
- Update stable version in repo from 3.0.3 to 3.0.5
- Run discovery "slowly" in background once a day
- Transform discovery into a js-controller plugin to be controlled via messages
- ping do not work in lxc containers HOT 1
- Update stable version in repo from 3.0.5 to 3.1.0
- Update stable version in repo from 3.1.0 to 3.2.0 HOT 1
- Update stable version in repo from 3.1.0 to 4.2.0 HOT 3
- Add generic MDNS/UPNP discovery and propose adapters
- Allow to specify the network segment(s) to scan HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iobroker.discovery.