Zusammenfassung

  • In den geprüften Quellen reicht RIPE Atlas Tools seine HTTP-Einstellung von zehn Sekunden an Googles Geokodierung weiter, nicht aber an die Atlas-Messungserstellung über Cousteau.
  • Ein lokaler Test mit den Werten 3, 10 und 30 bestätigt diese Parametergrenze ohne Netzwerkzugriff, Schlüssel, Messungen oder Kreditverbrauch. Er belegt keinen Betriebsausfall und erfasst nicht jede Installation.

Der Geltungsbereich steht im Aufruf

Die Einstellung heißt http-timeout und sieht damit nach einer allgemeinen HTTP-Regel aus. In RIPE Atlas Tools lässt sich ihr tatsächlicher Geltungsbereich jedoch nur am jeweiligen Aufruf ablesen. Die Geokodierung bekommt den Wert. Der untersuchte Weg zur Erstellung einer Atlas-Messung bekommt ihn nicht.

Die offizielle Änderungsliste datiert Version 3.4.0 auf den 3. Juni 2026 und führt einen konfigurierbaren HTTP-Timeout mit zehn Sekunden als Standardwert auf. Diese Untersuchung im September prüft die bereits veröffentlichte Arbeit. Sie meldet keine neue September-Version.

Bei der Suche nach Probes wandelt eine Methode einen Ortsnamen mithilfe von Google in Koordinaten um. Sie übergibt den konfigurierten Wert ausdrücklich an Requests und behandelt Timeout-Fehler. Die Einstellung hat dort einen nachweisbaren Verbraucher. Sie insgesamt für wirkungslos zu erklären wäre ebenso falsch wie eine allgemeine Abdeckung anzunehmen.

Die Messungserstellung läuft über das SDK. Der CLI-Aufruf übergibt AtlasCreateRequest den API-Server, den Autorisierungsschlüssel, die Clientkennung, Messungsdefinitionen, Probe-Quellen und die Kennzeichnung einer einmaligen Ausführung. Die HTTP-Einstellung fehlt.

Im geprüften Cousteau 2.3.0 erbt die Erstellungsklasse von AtlasRequest. Dessen HTTP-Argumente umfassen Parameter, Header, TLS-Prüfung und Proxys; beim POST kommt der JSON-Inhalt hinzu. Der abschließende Requests-Aufruf erhält dieses Wörterbuch ohne Timeout-Argument. Die gemeinsame institutionelle Umgebung der Pakete erzeugt keine automatische Vererbung einer CLI-Konfiguration.

Eine Prüfung ohne Fernauftrag

Für die Analyse wurden die echten Methoden zur Erstellung und Geokodierung sowie die Request- und Erstellungsklassen aus dem Syntaxbaum der festgehaltenen Quellen entnommen. Sie liefen lokal mit synthetischen Messungsdefinitionen und Quellenobjekten. Anstelle des Netzwerktransports zeichneten Funktionen die Argumente auf und lieferten lokale Testdaten zurück.

Bei den Einstellungen 3, 10 und 30 erhielt die Geokodierung jeweils genau diesen Wert. In allen drei aufgezeichneten Atlas-POSTs fehlte ein Timeout-Argument. Dem extrahierten Code standen keine Netzwerkfunktionen zur Verfügung. Es gab keinen API-Schlüssel, keine erzeugte Messung, keinen Fernauftrag und keinen Kreditverbrauch.

Geprüft wurde damit die Weitergabe eines Parameters in bestimmten Klassen und Methoden. Nicht geprüft wurden die vollständige installierte Kommandozeilenanwendung, das Zusammenspiel sämtlicher Module oder das Verhalten eines Servers. Auch eine Latenzmessung war dies nicht. Daraus folgt weder, dass ein Nutzer dreißig Sekunden wartete, noch dass Atlas ausfiel.

Diese Begrenzung gehört zum Befund. Der fehlende Parameter beschreibt einen Clientpfad. Welche zusätzliche Kontrolle eine reale Installation besitzt und welche Folgen der Pfad dort hatte, bleibt ohne weitere Belege offen.

Zehn Sekunden sind keine Gesamtlaufzeit

Requests erklärt in seiner Dokumentation, dass ohne ausdrücklich gesetzten Timeout seine Aufrufe keinen spezifizierten Requests-Timeout haben. Zugleich ist ein gesetzter Wert keine Obergrenze für den vollständigen Download einer Antwort. Eine Wartebedingung an der Verbindung ist etwas anderes als ein Gesamtbudget für eine Aufgabe.

Auch die Geokodierung verspricht deshalb kein Ende exakt zehn Sekunden nach dem Start des Kommandos. Umgekehrt bedeutet das fehlende Atlas-Argument nicht, dass jede Installation ewig warten muss. Betriebssystem, Verbindung, Proxy oder externe Prozessaufsicht können die Wartezeit beenden. Deren Regeln wurden hier nicht untersucht.

Der HTTP-Wert ist außerdem vom Paket-Timeout einer Probe und von der Beobachtungszeit eines Ergebnisempfängers zu trennen. Eine verspätete Antwort auf die Erstellung sagt nichts über die Geschwindigkeit der Probes oder des zu messenden Netzpfads aus.

Unbekannt ist nicht abgelehnt

Ein denkbarer Ablauf zeigt die Bedeutung: Der Server nimmt einen Erstellungsauftrag an, seine Antwort geht verloren, der lokale Prozess wird beendet. Das Ende des Clients belegt dann keine Ablehnung des Fernauftrags. Dies ist ein Szenario, kein Ereignis aus dem netzwerkfreien Test.

Vor einer erneuten Einreichung müsste der Betreiber einen Fernnachweis prüfen, auf den er berechtigt zugreifen darf, oder den Ausgang ausdrücklich als unbekannt erhalten. Eine lokale Frist ist kein Ablehnungsbescheid des Servers. Ein gestoppter Client ist nicht automatisch ein stornierter Fernauftrag.

Eine brauchbare Betriebsbeschreibung würde Googles Geokodierung, den Atlas-Pfad des SDK und das Gesamtbudget der Automatisierung getrennt benennen. Jede Operation kann eine andere Regel benötigen. Entscheidend ist, wer die Kontrolle liefert und wer nach ihrem Eingreifen den Ausgang klärt.

Quellen