upnp method does not reliably find all ssdp servers in the network

[pdbjjens]

upnp method does not reliably find all ssdp servers in the network

[pdbjjens]

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.

[Apollon77]

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.

[pdbjjens]

@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