generated from Dicken/dickendock
round43: Timeout wieder etwas grosszuegiger, Ports 80/443 bekommen immer einen zweiten Versuch (behebt verpasste Ports bei WLAN-angebundenen Geraeten wie Mesh-Repeatern)
This commit is contained in:
@@ -116,7 +116,17 @@ export async function scanDeviceServices(
|
||||
// überfordern und dabei ausgerechnet den einen tatsächlich offenen Port
|
||||
// verpassen - das führte zu falschen "nicht mehr gefunden"-Meldungen,
|
||||
// obwohl sich am Gerät nichts geändert hatte.
|
||||
const missedPriorityPorts = priorityPorts.filter((p) => !openPorts.includes(p));
|
||||
// Bereits bekannte Dienst-Ports (priorityPorts) UND immer 80/443 (die
|
||||
// wichtigsten, am meisten erwarteten Web-Ports überhaupt) bekommen einen
|
||||
// zweiten, einzelnen Versuch mit mehr Zeit, falls der erste, stark
|
||||
// parallele Durchlauf sie verpasst hat. Grund: viele gleichzeitige
|
||||
// Verbindungsversuche können schwächere/per WLAN angebundene Geräte (z. B.
|
||||
// ein FritzOS-Mesh-Repeater, Echo-Lautsprecher, Smart-TVs) kurzzeitig
|
||||
// überfordern oder brauchen einfach etwas länger als der knappe
|
||||
// Batch-Timeout - das führte sonst zu falschen "nicht gefunden"-Meldungen
|
||||
// ausgerechnet bei 80/443, obwohl der Dienst da ist.
|
||||
const mustRetryPorts = Array.from(new Set([...priorityPorts, 80, 443]));
|
||||
const missedPriorityPorts = mustRetryPorts.filter((p) => !openPorts.includes(p));
|
||||
const retryResults = await Promise.all(
|
||||
missedPriorityPorts.map(async (port) => ({ port, open: await isPortOpen(device.ip, port, 1500) }))
|
||||
);
|
||||
|
||||
@@ -44,19 +44,19 @@ export function isPortOpen(host: string, port: number, timeoutMs = 800): Promise
|
||||
* prüfen wäre bei 65535 Ports zu viel gleichzeitig offener Sockets; komplett
|
||||
* nacheinander wäre selbst bei schnellen RSTs zu langsam.
|
||||
*
|
||||
* Timeout bewusst knapp (300ms): im lokalen Netz (derselbe Subnetz-Bereich)
|
||||
* liegt die Round-Trip-Zeit normalerweise im niedrigen einstelligen
|
||||
* Millisekundenbereich - 300ms ist selbst dafür noch großzügig bemessen.
|
||||
* Der vorherige Wert von 600-800ms war für WAN-Verbindungen gedacht, nicht
|
||||
* fürs Heimnetz, und hat bei geschlossenen/gefilterten Ports (die den
|
||||
* vollen Timeout ausschöpfen) über ~131 Batches hinweg spürbar Sekunden
|
||||
* gekostet.
|
||||
* Timeout bewusst knapp, aber nicht zu knapp (500ms): im lokalen Netz
|
||||
* (derselbe Subnetz-Bereich) liegt die Round-Trip-Zeit normalerweise im
|
||||
* niedrigen einstelligen Millisekundenbereich, ABER per WLAN angebundene
|
||||
* Geräte (Mesh-Repeater, IoT-Geräte) können spürbar länger brauchen. Ports
|
||||
* 80/443 sowie bereits bekannte Dienst-Ports bekommen zusätzlich einen
|
||||
* zweiten, noch großzügigeren Versuch (siehe scanDeviceServices), falls
|
||||
* dieser erste, knappe Durchlauf sie verpasst.
|
||||
*/
|
||||
export async function scanPortsInBatches(
|
||||
host: string,
|
||||
ports: number[],
|
||||
batchSize = 1000,
|
||||
timeoutMs = 300
|
||||
timeoutMs = 500
|
||||
): Promise<number[]> {
|
||||
const open: number[] = [];
|
||||
for (let i = 0; i < ports.length; i += batchSize) {
|
||||
|
||||
Reference in New Issue
Block a user