mdg-filius/CHANGES.md

Herkunft und Änderungen

Nach GPL §5a: was aus welcher Quelle übertragen und wie es verändert wurde. Swift-Pfade relativ zu filius-ipad/ios/FiliusPad/TopologyEditor/ (Stand 3b5ded0, 27.08.2026), Tests relativ zu filius-ipad/ios/FiliusPadTests/.

packages/core

Datei	Quelle	Art der Übertragung
src/ids.ts	Swift-Sortierung nach UUID.uuidString	neu, bildet die Swift-Ordnung nach
src/model/node.ts	Model/TopologyNode.swift	übertragen; Standard-Ports und -Namen wie Java; ein gegebener Name bleibt, auch leer (Java lässt Router unbenannt)
src/model/link.ts, src/model/graph.ts	Model/TopologyLink.swift, Model/TopologyGraph.swift	übertragen, bisher nur die Daten (Abfragen folgen mit dem Editor)
src/model/documentation.ts	Model/TopologyDocumentation.swift	übertragen; FNV-Kennung mit BigInt, gegen die IDs aus dem Swift-Import geprüft
src/runtime/config.ts	State/TopologyEditorState.swift (Laufzeit-Konfigurationen, WLAN eines Rechners, DHCP, Portweiterleitung, Remote Link ohne LAN-Transport, Programme und ihre Konfiguration, Firewall, DNS-Einträge aus State/TopologyDNSResolver.swift, E-Mail-Konten und -Nachrichten aus State/TopologyEmail.swift); dazu Echo-Server- und Client-Konfiguration, die Swift nicht speichert	übertragen; Java-Beschriftungen der Oberfläche weggelassen
src/runtime/engine.ts	State/TopologyNetworkRuntimeEngine.swift Z. ~313–3585, ~4472–5187 (UDP), ~4753–4850	übertragen: Warteschlange, Uhr, Ethernet, Switch, ARP, IPv4, ICMP, Routing, Firewall, UDP-Sockets (binden, freie Ports nach Javas Zufall, senden samt Broadcast, zustellen, empfangen mit Wartezeit, schließen), TCP (Z. ~5187–5913: Server- und Client-Sockets, Handschlag mit Ergebnis, Segmente zu 1460 Byte bis zum PSH, höchstens drei Versuche, Abbau über alle Java-Zustände samt TIME_WAIT; seit F2.3c nach Javas TCPSocket an Java-Filius gemessen: je Versuch und für TIME_WAIT 3 RTT nach der Geschwindigkeit (8250 ms bei 90 %, Swift fest 7500 bzw. 2500 ms), der Zeitablauf zählt ab der Übergabe des Segments, vor ARP; ein Segment beendet TIME_WAIT; die Gegenseite schließt beim FIN von selbst; nicht bestätigte Daten schließen mit FIN statt sofort; der angenommene Socket hat die Startnummer des Listeners, der Listener eine neue. seit F2.3e wie Java: SYN+ACK und FIN gehen nie ein zweites Mal hinaus; der Server gibt einen Handschlag nach 3 RTT auf und schließt mit FIN; nach dem FIN wartet ein Socket höchstens fünfmal 3 RTT, jedes Segment beendet eine Wartezeit, dann CLOSED (Java lässt den Zustand stehen). Abweichend von Java: drei SYN statt einem, weil Javas Wiederholungsschleife nach dem ersten Zeitablauf abbricht, und ein wiederholtes SYN in SYN_RCVD bekommt das SYN+ACK noch einmal, statt den Socket zu schließen), DHCP (Z. ~5913–6694: Server mit festen Zuordnungen, Adressbereich, Angeboten, Leases und Sperrliste; Client seit F2.3b nach Javas DHCPClient neu gebaut und an Java-Filius gemessen: je Versuch eine Nachricht, eine Antwort, die nicht passt, wird gelesen und verworfen; die ARP-Prüfung wartet eine RTT, eine Antwort für die Adresse beendet sie sofort, dann DECLINE; nach einem Zeitablauf wiederholt der Zustand seine Nachricht, nach dem fünften nimmt der Client eine Link-Local-Adresse 169.254.1.x/16 (ARP-Probe, ARP-Reply an alle) und gibt keine alte Adresse zurück; Swift sendete doppelt, wartete nicht auf ARP und kehrte nach zehn Versuchen zur alten Adresse zurück. Abweichend von Java: Nach fünf belegten Link-Local-Adressen gibt der Client auf (Java sucht endlos), und ein ARP-Paket für eine andere Adresse beendet die Prüfung nicht. Seit F2.3d befördert ein Kabel einen Frame nach dem anderen wie Javas SimplexVerbindung (ein Frame wartet im Ausgangspuffer, bis der vorige angekommen ist, und erscheint im Protokoll, wenn er losgeht); Swift schickt alle zugleich, die Option swiftCables behält das für den Swift-Vergleich. Die RTT der DHCP-Zeiten (Warten, Angebote, Sperrliste) folgt wie in Java der Geschwindigkeit (50 Kabel, 2750 ms bei 90 %); Swift rechnet fest mit 2500 ms. ARP seit F2.4b nach Javas holeARPTabellenEintrag, an Java-Filius gemessen: eine Auflösung fragt, wartet eine RTT, fragt ein zweites Mal und gibt nach einer weiteren RTT auf; dann „Host unreachable" beim Absender selbst oder vom Router zurück (bei ICMP nur für Echo-Anfragen); ein wartender Absender wacht nach den übrigen Ereignissen desselben Zeitpunkts auf; der Ping wartet danach eine RTT auf die Antwort. Swift schickt in der Ereignisverarbeitung beide Anfragen zugleich und lässt das Paket ohne Ende warten, wenn die Adresse irgendwo im Netz vorkommt (Wissen, das kein Knoten hat), und blockiert direkte Aufrufe ohne Wartezeit; die Option swiftArp behält das für den Swift-Vergleich. Seit F2.4b-2 kehrt ein Senden wie in Java sofort zurück, die Frames reisen, während die Uhr läuft (Swift: der Aufruf kehrt erst zurück, wenn alle Frames angekommen sind; die Option swiftSends behält das für den Swift-Vergleich), und UDP und TCP senden über Javas Transport-Thread je Knoten und Protokoll: ein Segment nach dem anderen; solange IP auf ARP wartet, blockiert das nächste senden. Wartende Absender kommen in der Reihenfolge an die Reihe, in der sie kamen (Javas Sperre überlässt das dem Zufall). Seit F2.4b-3 geht jedes ankommende Paket wie in Java durch den IP-Thread (UDP, TCP) oder den ICMP-Thread (ICMP) seines Knotens: zustellen, Echo-Reply, weiterleiten, eins nach dem anderen; solange ARP wartet, warten die folgenden. Abweichend von Java weckt eine ARP-Antwort alle, die auf die Adresse warten (Javas notify weckt einen beliebigen). DNS seit F2.4a nach Javas DNSServer/Resolver, an Java-Filius gemessen: Server auf Port 53 mit Einträgen aus dem Modell (die Antwort wiederholt die Frage nicht, RCODE immer 0, ein Verweis mit NS und A im Antwortteil), iterativer Resolver mit 5 RTT je Anfrage, der nur die Server behält, an die er verwiesen wurde; seit F2.4c auf den Ereignissen statt blockierend und mit rekursivem Server nach DNSServer.answerWithRemoteData (Nameserver der Zone, dann der eigene DNS-Server, sonst Verweis), abweichend von Java fragt er sich nie selbst (Java endlos). Gateway-NAT seit F2.6 (Z. ~3585–3900) nach Javas filius.software.nat, an Java-Filius gemessen: die Übersetzung vor dem IP-Thread (wie Javas NAT-Threads zwischen Karte und Ethernet), ausgehend WAN-Adresse und der Port des Eintrags (ICMP behält die Kennung), eingehend nach Gegenstelle, Port und Protokoll, sonst nach der Portweiterleitung (legt einen dynamischen Eintrag an), ein Ping an die WAN-Adresse beantwortet der Heimrouter, Pakete von außen an das LAN verschwinden, beide Seiten durch die Firewall des Heimrouters, ausgehend TTL 1 bekommt „Zeit überschritten“; dynamische Einträge verfallen nach 300 s mal Javas Verzögerungsfaktor (Swift fest 300 s), aufgefrischt nur eingehend, seit 01.10.2026 genau in diesem Alter (Java findet sie erst bei seiner sekündlichen Prüfung, bis zu 1 s später; so auch der Switch: Javas checkSAT prüft jede Sekunde, der Kern verfällt genau zur Lernzeit); der Heimrouter leitet weiter wie ein Router. Abweichend von Java: ein LAN-Endpunkt bekommt für jede neue Gegenstelle einen Eintrag auf demselben WAN-Port (Java behält nur den für die erste, die Antworten weiterer bleiben am Heimrouter hängen). RIP seit F2.5a (Z. ~4700–5090) nach Javas filius.software.rip, seit F2.5b an Java-Filius gemessen (die Pause in Javas float-Rechnung): eine Route mit 0 Hops je eigenem Netz, die nie verfällt; der erste Beacon nach einer Sekunde, dann alle 25,2–35,2 s aus einem Zufall je Router (Java: ein ungesetzter Random je Router; der Kern setzt ihn aus Szenario und Router-ID, ripSeed; Swift: ein Zufall für alle); eine Nachricht je Schnittstelle ohne die Routen über sie (Split Horizon); eine neue Route oder mehr Hops vom selben Router senden sofort; eine gelernte Route wird genau nach ihren 75 s auf 16 gesetzt und sofort gemeldet (Java erst beim nächsten eigenen Beacon, bis zu gut 30 s später; Swift bei jedem Ereignis; seit 01.10.2026, vorher wie Java); Nachrichten von jedem Quellport (Swift: nur 521); ein RIP-Router leitet nur nach seiner Tabelle weiter, wenige Hops vor langer Maske. receiveUdp kehrt wie Javas empfangen zurück, sobald ein Datagramm da ist. Seit der Abnahme F2 nach Javas ARPThread: ein Eintrag entsteht nur aus einer Anfrage nach der eigenen Adresse oder aus einer Antwort (Swift: aus jedem Paket; swiftArp behält das), ein Paket von der Netzadresse wird verworfen; ein Rechner leitet weiter, wenn seine IP-Weiterleitung an ist (ipForwardingByNodeId). Seit F2.8b nach Javas Tabellen gemessen: eine ARP-Anfrage trägt als Ziel-MAC die Broadcast-Adresse (Swift: Nullen; swiftArp behält sie), eine ICMP-Fehlermeldung Identifier und Sequenznummer 0 (RFC 792, Java; Swift kopiert die des Echos, ein Ping erkennt die Meldung am eingebetteten Echo), und „Host nicht erreichbar“ vom Router trägt das Paket, wie er es weitergeleitet hat (TTL gesenkt). Die Broadcast-Adresse schreibt sie immer groß (Java in der Antwort an 0.0.0.0 klein). Den Mitschnitt je Karte (capture.ts) schreibt sie seit F2.8a dort, wo Java ihn schreibt: beim Abgang auf das Kabel und bei der Ankunft an der Karte. Seit F3.4a läuft die Befehlszeile mit (terminal, auf den Dateien des Knotens). Seit F3.4b nach Javas ICMP/ICMPThread, an Java-Filius gemessen: ein Echo im Programm-Thread (icmpEchoSteps: Warteschlange leeren, senden mit ARP-Wartezeit, eine RTT auf die erste ICMP-Nachricht warten, gleich welche), ein ICMP-Paket an den Broadcast eines eigenen Netzes geht mit TTL 1 an alle und wird von dort beantwortet, einer für ein fremdes Netz verworfen; Javas Routenwahl (routeRow), die ARP-Tabelle mit Javas Broadcast-Zeile (arpTable, removeArpEntry, resetArpTable), DNS im Programm-Thread mit Antwort- und Autoritätsteil (resolveDnsSteps), ein UDP-Socket weiß, dass er ohne Gegenstelle lauscht (listening); ein Rechner nimmt Pakete an 127.0.0.1 an. Eine ARP-Wartezeit endet wie Javas wait nach allem, was zur selben Zeit sonst geschieht (eine Antwort zur selben Millisekunde zählt noch). Seit F3.4c die Uhrzeit eines Frames (wallTime) für tcpdump. Seit F3.6a läuft das Gnutella-Programm mit (gnutella, Schnappschuss gnutellaByNodeId), mit eigener Zufallsquelle für die GUIDs (drawGnutellaGuid). Seit F3.5a schreibt der Mailserver seine Kontendatei /mailserver/konten.txt beim Start und bei jeder Änderung seiner Konten in die Dateien des Knotens (Java schreibt die Benachrichtigung an einen lokalen Absender erst beim nächsten Speichern hinein). Abweichend von Java: eine Echo-Antwort kommt von der gefragten Adresse (RFC 792; Java antwortet von 127.0.0.1, wenn die eigene Adresse gefragt war, und von der nahen Karte, wenn die ferne eines Routers gefragt war), und „Netz nicht erreichbar“ vom Router trägt wie „Host nicht erreichbar“ das Paket, wie er es weitergeleitet hätte, mit Absender (Java bettet ein halb gebautes ohne Absender ein). Seit F3.3b läuft das E-Mail-Programm mit (emailClient), seine gesendeten und abgeholten Mails stehen im Schnappschuss (emailClientsByNodeId); ein Programm-Thread kann MX nachschlagen (resolveDnsMailServerSteps). Seit F3.3a läuft der E-Mail-Server mit (emailServer); was er annimmt oder löscht, steht im Schnappschuss (emailServersByNodeId), aus dem es zurück ins Projekt geht; die Uhrzeit für seine Benachrichtigungen kommt aus der Option wallClock. Seit F3.2c ändert die Seite konfig der Router und Heimrouter die Firewall zur Laufzeit; die Änderung steht im Schnappschuss (firewallConfiguration), aus dem sie zurück ins Projekt geht. Seit F3.2b starten Router und Heimrouter ihren Webserver auf Port 80 mit Javas Seiten (Javas Server lauscht wegen eines Wettlaufs in setAktiv manchmal nie, der Kern immer; swiftRouters lässt ihn für den Swift-Vergleich weg), die Firewall führt ein Protokoll je Knoten (Regeltreffer bei TCP und UDP, verworfenes ICMP), das wie Javas Protokollseite einen Neustart überlebt, eine RIP-Route kennt die öffentliche Adresse des meldenden Routers (hopPublicIp), und TCP zählt Sequenznummern und Segmentgröße wie Java in Zeichen (UTF-16-Einheiten) statt in Bytes, ohne ein Zeichenpaar zu zerreißen; Bytes, die kein Text sind, zählen als Bytes. Seit F3.2a schließt ein Programm wie Javas schliessen() nur auf Bitte (requestTcpClose): Das FIN geht zur selben Zeit, nach dem, was der Programm-Thread noch tut. Seit F3.1 laufen Verbinden, Senden, Empfangen und Annehmen auch als Schritte eines Programm-Threads (connectTcpSteps, sendTcpSteps, receiveTcpSteps, acceptTcpSteps, resolveHostSteps); die blockierenden Aufrufe sind nur noch eine Hülle darum. Abweichend von Java: Ein Verbindungsaufbau ohne Route scheitert sofort (Javas Socket-Thread stirbt an der RouteNotFoundException, verbinden wartet ewig), eine Nachricht, die vor dem Schließen ankam, wird noch ausgegeben (Java verwirft sie), und Senden unterscheidet wie Java „nicht verbunden", „unterbrochen" und „Zeitüberschreitung". WLAN seit F2.7 an Java-Filius gemessen: zur Laufzeit ist ein Funkkabel ein Kabel wie jedes andere, und eine SSID verbindet nichts (nach ihr legt nur Javas Editor das Funkkabel, JHostKonfiguration.updateWifiConnection); Swifts Verbindung über die SSID zur Laufzeit, auch ohne Kabel (wirelessAssociations), nicht übernommen. Klasse statt Werttyp. Noch nicht übertragen (wirft NotPortedError): Remote Link
src/runtime/threads.ts	Javas Threads der Programme (Anwendung extends Thread, ServerMitarbeiter)	neu (F3.1): ein Programm-Thread als Generator, der liefert, worauf er wartet (Bedingung, Zeit oder beides); die Engine setzt nach jedem Ereignis fort, wessen Warten vorbei ist, in der Reihenfolge, in der die Threads begannen; nichts blockiert die Engine. Abweichend von Java: ein Thread wacht sofort, wenn seine Bedingung gilt (Java sieht oft nur alle 100 ms nach)
src/runtime/apps/program.ts	Java filius.software.Anwendung	neu (F3.1): die Zeilen im Fenster eines Programms (strukturiert, damit der Editor sie übersetzt) und der Befehls-Thread (ausfuehren)
src/runtime/apps/server.ts	Java ServerAnwendung, ServerMitarbeiter	neu (F3.2a, aus echo.ts herausgelöst): was jeder Server teilt — ein Thread nimmt Verbindungen an, solange er eingeschaltet ist, je Verbindung einer beantwortet jede Nachricht; ausgeschaltet schließt er Socket und Verbindungen; Port belegt → er schaltet sich aus; seit F3.3a kann ein Server das Gespräch einer Verbindung selbst führen (converse: Begrüßung, keine oder mehrere Antworten, Schließen)
src/runtime/apps/web.ts	Java filius.software.www (WebServer, WebServerMitarbeiter, WebBrowser), die Adresszeile aus GUIApplicationWebBrowserWindow.erzeugeURL	neu nach Java (F3.2a): Webserver (Dateien unter /webserver, index.html für /, virtuelle Hosts aus /www.conf/vhosts, fünf Zeilen, ohne Rücksicht auf Groß- und Kleinschreibung, Inhaltsart nach dem Dateinamen, Bilder und Binärdateien in Javas Base64) und Browser (immer Port 80, Seite, dann ihre Bilder nacheinander über dieselbe Verbindung, dann schließen; Link ohne Host geht an den letzten). An Java-Filius gemessen. Abweichend von Java: nichts außerhalb von /webserver (Java löst /../ auf und liefert jede Datei des Rechners), 400/501 statt eines stummen Abbruchs bei unlesbaren Anfragen, eine Anfrage ohne Version gilt als HTTP/1.1, der Browser zeigt „Server nicht erreichbar“, wenn keine Antwort kommt (Java nichts). Seit F3.2c wie Java: Eine Methode, die nicht genau GET oder POST heißt (get), wird gelesen und mit 501 beantwortet (vorher die Seite)
src/runtime/apps/routerPages.ts	Java VermittlungsrechnerBetriebssystem, GatewayFirmware, FirewallWebLog, VermittlungWeb, FirewallRule.toString, Vorlagen tmpl/vermittlung_index, gateway_index, routing (de, en)	neu nach Java (F3.2b): die Seiten der Router und Heimrouter in der Sprache des Projekts — Index, routes (Weiterleitungs- oder RIP-Tabelle mit Javas Farben, Gültigkeit in ganzen Sekunden) und log (Firewall-Protokoll); die Vorlagen per Skript aus Javas Ressourcen übernommen (Zeilen wie Javas readLine mit \n). Abweichend von Java: </title> statt Javas </titel> auf der deutschen Protokollseite
src/runtime/apps/firewallSettings.ts	Java FirewallWebKonfig, Vorlage tmpl/firewall_konfig_webseite (de, en), EingabenUeberpruefung (musterPort, isValidSubnetmask)	neu nach Java (F3.2c): die Seite konfig der Router und Heimrouter — allgemeine Einstellungen, Standardaktion, Regeln verschieben, löschen, hinzufügen; Fehlerliste und wieder gefülltes Formular, wenn eine Regel nicht passt; Vorlagen per Skript aus Javas Ressourcen. An Java-Filius gemessen (KonfigCases, RouterWebRun). Abweichend von Java: ein Feld wird erst gegen die anderen geprüft, wenn alle gelesen sind (Java prüft die IP gegen die noch ungelesene Maske und umgekehrt und nimmt so keine Regel mit Adresse an); ein Fehler steht nur auf der Antwort auf das gescheiterte Hinzufügen (Java zeigt ihn auf jeder späteren Seite); bei mehreren Knöpfen kein Fehler ohne Hinzufügen (Java schreibt die nackte Liste); Text aus dem Formular wird maskiert (Java schreibt ihn roh, ein „$“ ließ die Seite scheitern); die Daten werden zerlegt, bevor sie dekodiert werden (Java dekodiert zuerst, ein getipptes „&“ zerriss das Formular), ein Feld ohne gültige URL-Kodierung gilt, wie es kam (Javas Dekodierer wirft, keine Seite kommt); Regel 0 nach unten tut nichts (Java wirft)
src/runtime/http.ts	Java HTTPNachricht, Spring UriUtils.encodePath/decode, java.net.URLDecoder	neu nach Java (F3.2a): Anfragen und Antworten in Javas Textform, Javas Statustexte, Pfade kodiert wie UriUtils; seit F3.2c javaUrlDecode für Formulardaten wie URLDecoder.decode (UTF-8, + als Leerzeichen, scheitert, wo Java wirft)
src/util/javaBase64.ts	Java filius.rahmenprogramm.Base64 (iHarder)	aus packages/fls (exportProject.ts) in den Kern gezogen (F3.2a), dazu der Leser, der Leerraum überspringt
src/runtime/email.ts	Java filius.software.email.Email, AddressEntry, EmailUtils	neu nach Java (F3.3a): Mails in Javas Textform (From, To, Cc, Subject, Date Received, Leerzeile, Text; kein Bcc), Adressen „Name “, Javas Größe einer Mail für POP3. Abweichend von Java: der Kopf endet an seiner Leerzeile, ein unbekanntes Feld wird übergangen (Java beendet dort den Kopf und liest die folgenden Felder als Text), eine Zeile ohne Feld beginnt den Text (Java verwirft sie)
src/runtime/emailAccountsFile.ts	Java EmailServer.listeBenutzerkontenZuString	neu (F3.5a): die Kontendatei des Mailservers aus seinen Konten, aus packages/fls (Export) hierher verschoben, damit Export und Laufzeit dasselbe schreiben; Javas Fehler wie dort nicht übernommen
src/runtime/apps/emailServer.ts	Java EmailServer, SMTPServer, SMTPMitarbeiter, POP3Server, POP3Mitarbeiter, EmailKonto	neu nach Java (F3.3a): Konten einer Domain, SMTP auf Port 25 speichert Mails an eigene Konten (wie Java neu gelesen) und schickt bei unbekannten Empfängern eine Benachrichtigung an einen Absender der Domain, POP3 auf Port 110 gibt Mails ab 0 nummeriert aus; beide zusammen ein- und ausgeschaltet, POP3 zuerst; SMTP-Antworten in der Sprache des Projekts; Fensterzeilen wie Java. An Java-Filius gemessen (EmailRun, MailCases). Abweichend von Java: nach einer Mail ist der Umschlag neu (Java antwortet dem nächsten Befehl 503 und behält Absender, Empfänger und Text); ein Befehl, den der Zustand nicht nimmt, bekommt 503 (Java schweigt), HELO beginnt neu; in DATA ist alles Text, auch quit; die Domain gilt in jeder Schreibweise; ein Empfänger ohne @ ist unbekannt, ein leerer Absender bekommt keine Benachrichtigung (Java wirft), eine Benachrichtigung an eine Mail ohne From geht an den Absender des Umschlags (Java: To: null); POP3: eine Mail lässt sich mehrmals abrufen, eine fehlende Mail, LIST ohne Mails und falsche Argumente geben -ERR (Java: leere Mail, leere Antwort, Abbruch), LIST n listet die eine Mail, Nummern bleiben nach DELE (Javas LIST zählt neu), vor der Anmeldung -ERR unknown command, QUIT immer +OK. Seit F3.3b leitet der Server Mails an fremde Domains per MX weiter (in seinem eigenen Thread, je Weiterleitung ein neuer SMTP-Client) und schickt eine Benachrichtigung an einen fremden Absender mit leerem Absender an dessen Domain. Noch nicht: die Kontodatei /mailserver/konten.txt zur Laufzeit
src/runtime/apps/emailClient.ts	Java EmailAnwendung, SMTPClient, POP3Client, das Senden aus GUIApplicationEmailAnwendungWindow	neu nach Java (F3.3b): das E-Mail-Programm sendet eine Mail an den SMTP-Server seines Kontos, eine Verbindung je Empfänger (An, Cc, Bcc), und holt die Mails seines Kontos vom POP3-Server (jede abgerufen, dann gelöscht); die Prüfungen des Fensters (kein Konto, Adresse, die Javas Muster nicht nimmt, kein Empfänger); Meldungen wie Javas Beobachter (Verbindung, versendet, getrennt, Ausnahmen); der SMTP-Client dient auch dem Server zum Weiterleiten. An Java-Filius gemessen (EmailClientRun). Abweichend von Java: der SMTP-Port des Kontos gilt (Java verbindet immer zu 25); drei SYN statt einem
src/runtime/apps/filePrograms.ts	Java FileExplorer, TextEditor, ImageViewer und ihre Fenster, config/filetypes.txt, die Meldungen sw_fileexplorer_msg1–3, fileexplorer_msg19	neu nach Java (F3.5b): die Dateioperationen hinter den Knöpfen von Datei-Explorer (Ordnerliste, neuer Ordner, löschen, kopieren/ausschneiden/einfügen, umbenennen, importieren), Texteditor (speichern, speichern unter) und Bildbetrachter, auf den Dateien des Knotens; an Java-Filius gemessen (FileCases). Abweichend von Java: ein Ordnername, der zu keinem Namen wird, legt nichts an; Einfügen auf einen vorhandenen Namen wird abgelehnt (Java: zweiter Eintrag gleichen Namens); Umbenennen auf einen Namen mit / oder mit Leerzeichen am Rand wird abgelehnt, eine reine Änderung der Groß-/Kleinschreibung ausgeführt (Java lehnt sie ab); „Speichern unter“ und Import auf einen Ordnernamen werden abgelehnt (Java wirft); die Größe einer Textdatei sind ihre Zeichen
src/runtime/apps/gnutella.ts	Java filius.software.dateiaustausch (PeerToPeerAnwendung, PeerToPeerServer, PeerToPeerServerMitarbeiter, PeerToPeerClient, PeerToPeerClientMitarbeiter, PingPaket, PongPaket)	neu nach Java (F3.6a): Beitreten mit Ping und Pong in Javas Textformat über Port 6346, Weiterleiten an die eigenen Teilnehmer, Pongs auf dem Weg des Pings zurück, Höchstzahl der Teilnehmer, Zurücksetzen, Ordner /peer2peer; an Java-Filius gemessen (GnutellaRun). Die Swift-Fassung (TopologyRuntimeGnutella.swift, eigenes Protokoll) nicht übernommen. Seit F3.6b Suche mit Query und Treffern (weitergeleitet wie Pings, Treffer auf dem Weg der Query zurück), Ergebnisse, Download per HTTP über 6346 (QueryPaket, QueryHitPaket, httpAnfrageVerarbeiten, herunterladenDatei). Abweichend von Java: ein zweites Mal ankommender Ping bekommt keinen Pong, und seine Verbindung bleibt (Java wirft und schließt sie); wer Treffer geschickt hat, hält die Verbindung, damit auch die Treffer der weiter entfernten Teilnehmer zurückkommen (Java schließt sie, die gehen verloren); Größen in Treffer und Pong in Zeichen (Java: Base64-dekodiert)
src/runtime/apps/terminal.ts, src/runtime/apps/terminalTexts.ts	Java filius.software.lokal.Terminal, die Eingabe aus GUIApplicationTerminalWindow, die Texte sw_terminal_* und terminal_msg* des Bündels	neu nach Java (F3.4a): die Befehlszeile mit Javas Zerlegung der Eingabe, Verteilung nach dem Befehlsnamen und den lokalen Befehlen ls/dir, cd, pwd, mkdir, touch, cp/copy, mv/move, rm/del, cat/type, test, help, ipconfig, route; Texte in der Sprache des Projekts, aus dem von Java geladenen Bündel erzeugt. An Java-Filius gemessen (TerminalCases). Abweichend von Java: die Größe einer Textdatei sind ihre Zeichen (Java dekodiert Base64); ein fehlender Ordner ist für ls „nicht vorhanden“, ls / nennt die Wurzel; cd auf eine Datei, touch/mkdir in fehlenden Ordnern und cp auf einen Ordnernamen scheitern; .. bleibt an der Wurzel; rm und mv nehmen absolute Pfade absolut, die Wurzel ist nicht löschbar, nach dem Löschen des Arbeitsordners gilt der nächste verbliebene darüber; mv auf die Datei selbst benennt sie um. Seit F3.4b die Netzbefehle ping (Strg+C über interrupt), host, nslookup, arp und netstat, mit Javas Laufmarken; ein unbekannter Befehl wird wie bei Java sofort gemeldet, auch während ein anderer läuft; seit F3.4c traceroute und tcpdump (arpsend nicht gebaut, der Befehl ist unbekannt); an Java-Filius gemessen (TerminalRun). Abweichend von Java: ping nennt den Host, wo Java seinen ersten Parameter nennt (-b in der Statistik), und nimmt vor dem Host nur -b (Java nimmt jedes Wort und pingt einen Broadcast); arp und netstat listen in der Reihenfolge des Lernens bzw. Anlegens (Java: Reihenfolge einer HashMap); netstat zeigt von einem UDP-Server nur den lauschenden Socket (Java auch einen für jede je beantwortete Adresse, nie geschlossen); traceroute sagt sein Fazit vor der Endmarke (Java danach, wo sein Fenster keinen Text mehr zeigt) und nennt ein Ziel beim 20. Sprung erreicht (Java: nicht erreicht); tcpdump meldet jeden Frame sofort (Java schaut alle 100 ms)
src/runtime/apps/echo.ts	Java filius.software.clientserver (ServerBaustein, ServerBausteinMitarbeiter, ClientAnwendung, ClientBaustein)	neu nach Java statt nach Swift (F3.1): Echo-Server (auf server.ts, sendet jede Nachricht zurück) und einfacher Client (verbinden über Adresse oder Namen, senden, empfangen, trennen), mit Javas Fensterzeilen. An Java-Filius gemessen. Abweichend von Java: Der Server merkt das Ausschalten, der Client die Verbindung sofort (Java alle 100 ms); ohne Route scheitert der Client sofort (Java wartet ewig ohne Meldung); ausgeschaltet bestätigt der Server noch das FIN seiner Verbindungen (Java gibt den Port frei, das FIN bleibt unbeantwortet)
src/runtime/dns.ts	Java filius.software.dns.DNSNachricht, Query, ResourceRecord	neu nach Java statt nach Swift (Swift ersetzt Javas Textnachrichten durch FILIUS-DNS-TYPED/1): Kopfzeile ID=… QR=… RCODE=… QDCOUNT=… …, Frage- und Eintragszeilen, Suche nach Namen ohne Rücksicht auf Groß- und Kleinschreibung, NS der längsten Zone, sonst der Wurzel
src/runtime/ipv4.ts	Engine parseIPv4/sameSubnet	übertragen
src/runtime/packets.ts	Engine, Paketmodelle	übertragen; Data → Uint8Array
src/runtime/random.ts	Engine, TopologyJavaCompatibleRandom	übertragen; BigInt für die 48-Bit-Arithmetik; dazu nextDouble (Javas Math.random, an OpenJDK 21 gemessen)
src/runtime/routeTable.ts	State/TopologyJavaRouteTable.swift	übertragen ohne Tabellengeometrie (gehört in den Editor)
src/runtime/snapshot.ts	Engine, TopologyNetworkRuntimeTopologySnapshot	übertragen, bisher mit den Feldern der übertragenen Schichten, seit der Abnahme F2 mit der IP-Weiterleitung, wo sie vom Standard der Art abweicht, seit F2.3 mit den DHCP-Einstellungen von Clients und Servern, seit F2.4a mit den eingeschalteten DNS-Servern, seit F3.1 mit den installierten Echo-Servern (Port, ein oder aus) und einfachen Clients, seit F3.2a mit den Webservern, Browsern und den Dateisystemen der Knoten, seit F3.2b mit der Sprache der Seiten, die Geräte selbst schreiben, seit F3.3a mit den E-Mail-Servern (Domain, Konten mit Postfächern, ein oder aus), seit F3.3b mit den E-Mail-Programmen (Konto, Ordner), seit F3.4a mit den Knoten, auf denen die Befehlszeile installiert ist; ohne Swifts WLAN-Einstellungen der Rechner (hostWirelessConfigurationsByNodeID), die zur Laufzeit nichts bewirken (F2.7)
src/runtime/speed.ts	Engine, TopologyNetworkRuntimeSpeed	übertragen; dazu Javas RTT (Verbindung.holeRTT: 50 Kabel), die Swift nicht kennt
src/runtime/trace.ts	Engine, Paketspur-Modell	übertragen
src/runtime/captureRows.ts	Java Lauscher.datenVorbereiten, classifyApplicationLayerProtocol, die toString von ArpPaket, IpPaket, IcmpPaket	neu nach Java (F2.8b): die Tabelle des Mitschnitts, je Frame eine Zeile je Schicht (Ethernet; ARP, ICMP oder IP; TCP oder UDP; die Daten, wenn Javas trim etwas übrig lässt), in beiden Ansichten Javas (Ende als Adresse:Port samt Datenzeile, oder nur Ports und die Datenzeile ohne Enden); die Bemerkung bleibt strukturiert, captureCommentText sagt sie mit gegebenen Wörtern und Zahlenformat wie Java. An Javas eigenen Tabellen gemessen. Abweichend von Java: „ICMP Time Exceeded“ (Java: „Exeeded“)
src/runtime/capture.ts	Java filius.rahmenprogramm.nachrichten.Lauscher	neu nach Java (Swift hat stattdessen die Paketspur je Schritt): der Mitschnitt je Netzwerkkarte, jeder gesendete und empfangene Frame einmal mit Zeit und Nummer, wie Java auch Frames an andere Karten und solche, die die Firewall verwirft; Switches ohne Liste; verlorene Frames getrennt; bleibt über Stopp und Neustart, geleert nur auf Wunsch. Abweichend von Java: je Port statt je MAC-Adresse (Java legt zwei Karten mit gleicher MAC zusammen) und höchstens 10.000 Frames je Karte, die ältesten 1.000 fallen auf einmal heraus, die Nummern bleiben (Java behält alles)
src/util/equal.ts	—	neu (Ersatz für Swifts Equatable)
src/util/swiftString.ts	—	neu: Swift-String-Verhalten, das der übertragene Code stillschweigend voraussetzt (Trimmen, Kleinschreibung je Skalar, kanonische Gleichheit, Sortierung nach Skalarwerten, Base64 wie Foundation); am Swift-Orakel gemessen, Leerraum und Steuerzeichen über ganz Unicode
src/model/virtualFileSystem.ts, src/model/defaultImages.ts	State/TopologyVirtualFileSystem.swift	übertragen; Schlüssel in NFC statt Swifts kanonischer Wörterbuch-Gleichheit; Steuerzeichen nach Unicode Cc+Cf, ohne Foundations Tabellenfehler in Ebene 14; seit F3.4a die Einträge eines Ordners auch in der Reihenfolge ihres Entstehens, wie Javas Dateibaum (entriesInCreationOrder); seit F3.5b renameInPlace: ein Eintrag behält beim Umbenennen seine Stelle, auch bei reiner Änderung der Groß-/Kleinschreibung, wie Javas Knoten (renameItem bleibt Swifts Verschieben); seit F3.6b javaFileTypeName und fileContentOfJavaType (Javas Dateityp aus der Art und zurück), aus Export und Import von packages/fls hierher, damit auch der Gnutella-Download sie nutzt
test/virtualFileSystem.test.ts, test/vfs.*.json	TopologyProjectPersistenceTests.swift, TopologyEditorReducerTests.swift (drei Dateisystem-Tests, als Fälle)	übertragen und erweitert: 11 Fälle, Ergebnis aus dem Swift-Kern
test/strings.test.ts, test/strings.*.json	—	neu: Fälle und ganze Zeichenmengen, Ergebnis aus dem Swift-Kern
test/engine.test.ts	TopologyNetworkRuntimeEngineTests.swift (21 von 72 Tests)	übertragen; nextInt- und nextDouble-Referenzwerte an OpenJDK 21 gemessen; die DHCP-Client-Tests seit F2.3b nach Javas Verhalten (neun, davon zwei benannte Java-Fehler, die der Kern nicht übernimmt); seit F2.8a sechs Tests für den Mitschnitt (über Neustart, Leeren, Obergrenze, verlorene Frames, Switches)
test/oracle.test.ts, test/scenarios/	—	neu: 14 Szenarien (davon 2 UDP, 3 TCP, 4 DHCP), Ergebnis mit dem Swift-Kern abgeglichen (tools/swift-oracle); Schritte für UDP, TCP und DHCP; die vier DHCP-Szenarien folgen seit F2.3b Java, die drei TCP-Szenarien seit F2.3c; sie müssen von Swift abweichen; drei weitere (firewall-and-loss, routed-two-networks, switch-lan) folgen seit F2.4b ab der Spur, an der ARP scheitert oder ein Ping unbeantwortet bleibt, Java und stimmen bis dahin mit Swift
test/dhcpJava.test.ts, test/scenarios/*.java.json, test/scenario.ts, test/javaRun.ts	—	neu: die DHCP-Szenarien gegen Java-Filius (tools/java-oracle, DhcpRun): je Client dieselben Frames in derselben Reihenfolge, Abstände auf 200 ms, dieselben Adressen am Ende
test/arpJava.test.ts, test/scenarios/arp-routed.scenario.json, test/scenarios/arp-java-*.java.json	—	neu: vier ARP-Abläufe gegen Java-Filius (ArpRun): Frames, Abstände und wann jeder Aufruf zurückkehrt; die zwei Pings stimmen seit F2.4b-1, die zwei UDP-Abläufe seit F2.4b-2 (Javas Transport-Thread), drei Abläufe durch den Router seit F2.4b-3 (IP- und ICMP-Thread)
test/natJava.test.ts, test/scenarios/nat-home.scenario.json, test/scenarios/nat-java-*.java.json	—	neu: sechs NAT-Abläufe gegen Java-Filius (NatRun): je Absenderkarte dieselben Frames in derselben Folge zur selben Zeit, dieselben Aufrufe, dieselbe NAT-Tabelle; freie Ports und TCP-Startnummern als Platzhalter; ein benannter Java-Fehler (JAVA_BUGS: die Antwort der zweiten Gegenstelle)
test/javaRun.ts (expectSameCaptures)	—	seit F2.8a: der Mitschnitt jeder Karte gegen Javas Liste dieser Karte (dieselben Frames, dieselbe Folge, dieselbe Zeit), in den Vergleichen für ARP, WLAN, DNS, TCP, NAT, RIP und DHCP mit einem Client; seit F2.8b für jeden dieser Frames auch Javas Tabellenzeilen in beiden Ansichten (Wörter und Zahlen wie Javas deutsches Gebietsschema); seit der Abnahme F3 wahlweise Fluss für Fluss (flow): wo Frames verschiedener Verbindungen in beliebiger Folge kommen, je Fluss in Folge, mit Zeit und Tabellenzeilen; und nur ausgewählte Frames (compared)
test/echoJava.test.ts, test/scenarios/echo-java-*.java.json	—	neu (F3.1): acht Abläufe mit Echo-Server und einfachem Client gegen Java-Filius (EchoRun): je Karte Frames, Zeiten und Tabellenzeilen, dazu die Fensterzeilen beider Programme auf Deutsch wie Java (Zeilen, die Java erst bei seinem 100-ms-Blick schreibt, dürfen dort bis zu 100 ms später kommen); drei benannte Java-Fehler (JAVA_BUGS: keine Route, nur ein SYN, das unbeantwortete FIN nach dem Ausschalten)
test/webJava.test.ts, test/scenarios/web-lan.scenario.json, test/scenarios/web-java-*.java.json, test/programLines.ts	—	neu (F3.2a): elf Abläufe mit Webserver und Browser gegen Java-Filius (WebRun, mit den Dateien des Servers): je Karte Frames, Zeiten, Tabellen, die Fensterzeilen des Servers, Seiten und Bilder des Browsers (Fehlerseiten nach Status); Javas Threads hinken bei langen Übertragungen bis zu 130 ms nach, verglichen auf 200 ms; drei benannte Java-Fehler (JAVA_BUGS: /../ liefert fremde Dateien, HALLO beendet die Verbindung stumm, nur ein SYN). programLines.ts: die Fensterzeilen der Programme auf Deutsch, geteilt mit echoJava.test.ts
test/routerWebJava.test.ts, test/scenarios/router-web.scenario.json, test/scenarios/routerweb-java-*.java.json	—	neu (F3.2b): sechs Abläufe mit den Seiten der Router und Heimrouter gegen Java-Filius (RouterWebRun): Index, Routen (Weiterleitung und RIP), Protokoll nach verworfenem Ping und Regeltreffern, Heimrouter von innen und außen; seit F3.2c drei mit konfig: die Seite, „ICMP filtern“ aus und der Ping kommt durch, eine Regel angelegt und nach oben geschoben sperrt den Browser aus (benannter Java-Fehler: nur ein SYN); Startnummern ohne die Million (Javas Router-Server lauscht nicht immer), die Gültigkeit der RIP-Routen als Platzhalter (Javas versetzter Start); ein benannter Java-Fehler (</titel>)
test/routerPages.test.ts	—	neu (F3.2b): Farben und Hops der Routen-Seite, RIP bei 16 Hops und Sekunden, Index in beiden Sprachen, Regeltexte, UDP im Protokoll und das Protokoll über einen Neustart, Server beim Start und swiftRouters, öffentliche Adresse bei kürzerem Weg, TCP in Zeichen; seit F3.2c konfig über das Netz: Änderung in den Schnappschuss, eine Seite ohne Daten ändert nichts, Englisch, Heimrouter
test/firewallSettings.test.ts, test/firewall-settings.cases.txt, test/firewall-settings.{de,en}.java.json	—	neu (F3.2c): 25 Fälle der Seite konfig gegen Java-Filius (KonfigCases), je Schritt Seite und Firewall, Deutsch und Englisch, darunter die Formulardaten, wie Javas Browserfenster (Swing) sie schickt; zehn benannte Java-Fehler (JAVA_BUGS), die erwartete Seite jeweils aus einem Java-Lauf mit demselben Zustand; dazu javaUrlDecode
test/web.test.ts	—	neu (F3.2a): HTTP-Form, Pfadkodierung, Base64, Adresszeile, Bildersuche; am Server 400/501 (seit F3.2c auch für get und Post), Durchgriff, Ordner, Inhaltsarten, Binärdateien, virtuelle Hosts (fünf Zeilen, Schalter ohne Datei); am Browser Seite und Bilder, Link ohne Host, nur HTML sucht Bilder, keine Adresse, keine Antwort
test/emailServer.test.ts, test/email-server.cases.txt, test/email-server.{de,en}.java.json, test/mailAccounts.ts	—	neu (F3.3a): 26 Fälle der SMTP- und POP3-Gespräche gegen Java-Filius (MailCases), je Nachricht Antworten, Fensterzeilen, Schließen und Konten, Deutsch und Englisch; 18 Fälle mit benannten Java-Fehlern (JAVA_BUGS); dazu Adressen, Mailtext und Größe, und im Kern: Ein- und Ausschalten, Postfächer im Schnappschuss und über einen Neustart, Datum der Benachrichtigung je Sprache
test/emailJava.test.ts, test/scenarios/mail-lan.scenario.json, test/scenarios/email-java-*.java.json	—	neu (F3.3a): vier Abläufe mit dem E-Mail-Server gegen Java-Filius (EmailRun): SMTP, SMTP mit Fehlern und Benachrichtigung, POP3 zweimal angemeldet, POP3-Anmeldefehler; je Karte Frames, Zeiten, Tabellen, die Fensterzeilen von Server und Client und die Konten am Ende (das Datum der Benachrichtigung als Platzhalter); seit F3.5a auch die Kontendatei am Ende, wie Java die Konten schreibt (und wo Javas hinterlassene Datei hinterherhinkt)
test/emailClientJava.test.ts, test/scenarios/email-client-java-*.java.json	—	neu (F3.3b): sechs Abläufe mit dem E-Mail-Programm und zwei Servern gegen Java-Filius (EmailClientRun): senden mit Weiterleitung, abholen, Server per Name und Benachrichtigungen von beiden Servern, falsches Passwort, kein Server, unbekannter Servername; je Karte Frames, Zeiten, Tabellen, die Meldungen von Programm und Servern, Posteingang, Gesendete und Konten am Ende; Javas 100-ms-Blick kostet je Verbindung (und je DNS-Antwort, auf die es so wartet) eine Periode Toleranz; ein benannter Java-Fehler (nur ein SYN); bei byName die Startnummern ohne die Million (Thread-Wettlauf in Java)
test/emailClient.test.ts	—	neu (F3.3b): was das Fenster ablehnt, Bcc, der SMTP-Port des Kontos, eine ungültige Kontoadresse, eine Verbindung, die beim Warten endet, eine Mail ohne Absender aus dem Modell, die Ordner im Schnappschuss
test/filePrograms.test.ts, test/file-programs.cases.txt, test/file-programs.{de,en}.java.json	—	neu (F3.5b): sechs Fälle der Dateiprogramme gegen Java-Filius (FileCases), je Schritt Rückgabe und alle Dateien, Deutsch und Englisch, benannte Java-Fehler (JAVA_BUGS); dazu Dateitypen, Ordnerliste, Bildbetrachter, leerer Ordnername
test/gnutellaJava.test.ts, test/gnutella.test.ts, test/scenarios/gnutella-java-*.java.json	—	neu (F3.6a, F3.6b): sechs Abläufe des Beitretens und zwei der Suche mit Download gegen Java-Filius (GnutellaRun), Ergebnisse und Dateien am Ende, je Karte die Frames samt Tabellen (wo viele Verbindungen zugleich laufen: je Verbindung und Richtung mit ihren Daten), die Teilnehmer jedes Programms mit Zeit; Javas GUIDs ersetzen die gezogenen, damit Längen und Sequenznummern gleich bleiben; dazu Paketformat, doppelter Ping, Kopf ohne Paket, Lebensdauer, Dateien im Pong
test/terminal.test.ts, test/terminal.cases.txt, test/terminal.{de,en}.java.json	—	neu (F3.4a): 16 Fälle der Befehlszeile gegen Java-Filius (TerminalCases), je Zeile die Handlung des Fensters, was das Programm sagt, Arbeitsordner und alle Dateien, Deutsch und Englisch; Javas Größe von Textdateien überall als Java-Fehler korrigiert, dazu acht Fälle mit benannten Java-Fehlern (JAVA_BUGS); ein Bild bleibt beim Kopieren ein Bild; jeder Text der Tabelle ist wörtlich Javas
test/terminalJava.test.ts, test/scenarios/terminal-net.scenario.json, test/scenarios/terminal-java-*.java.json	—	neu (F3.4b): zwölf Abläufe der Netzbefehle gegen Java-Filius (TerminalRun) auf einem LAN mit DNS-Server, Router und Rechner dahinter: ping im LAN, über den Router, ins Leere, hinter dem Router unerreichbar, ohne Route am Router, Broadcast, eigene Adresse, Fehler, Strg+C; host und nslookup, auch ohne erreichbaren DNS-Server; arp; netstat mit TCP-Verbindung und DNS-Server; je Karte die Frames samt Javas Tabellen, je Rechner Texte und Laufmarken mit Zeit; benannte Java-Fehler (JAVA_BUGS); die Reihenfolge der Antworten auf einen Broadcast ist ein Wettlauf von Javas Threads (je Sekunde als Menge verglichen); seit F3.4c neun Abläufe mit traceroute (LAN, über den Router, unerreichbar, ohne Route, ins Leere, eigene Adresse, Fehler, Strg+C) und tcpdump auf zwei Rechnern; ein Wächter verwirft Aufnahmen, in denen Java sein Aufwecken verpasst hat; dazu zehn Einzelfälle (traceroute über 20 Sprünge, Strg+C vor dem Start, fremde Echo-Antworten, gerundeter Verlust, Broadcast bei anderer Maske, zufälliger Identifier und sein Weiterzählen, gleich lange Routen)
test/apps.test.ts	—	neu (F3.1): wie Threads aufwachen (nach dem Ereignis, nach einer Pause hinter den anderen, ein Weckruf nur für sein Warten, Reihenfolge des Beginns, kein Warten auf schon Geltendes), und was die Java-Abläufe nicht zeigen: belegter Port, Name über DNS und ohne DNS, keine Route, unbestätigtes Senden, Neustart, eine Nachricht vor dem Schließen
test/captureRows.test.ts	—	neu (F2.8b): die Regeln der Tabelle, die kein Java-Lauf zeigt (GNT, POP3, SMTP, HTTP, Javas trim, ICMP-Fehler mit eingebettetem ICMP, Ansicht ohne Enden)
test/wlanJava.test.ts, test/scenarios/wlan-lan.scenario.json, test/scenarios/wlan-java-*.java.json	—	neu: vier Pings gegen Java-Filius (WlanRun): über Funkkabel, über ein Kabel und an ein Notebook mit der SSID des Switches, aber ohne Kabel (ARP scheitert in Java wie im Kern); Frames, Abstände, Ergebnis und Dauer
test/ripJava.test.ts, test/scenarios/rip-chain.scenario.json, test/scenarios/rip-java-*.java.json	—	neu: zwei RIP-Abläufe gegen Java-Filius (RipRun, der Zufall jedes Routers auf ripSeed gesetzt): je Absenderkarte dieselben Nachrichten zur selben Zeit, jede Tabelle durch dieselben Zustände, derselbe Ping; die ersten 5 s (Javas gestaffelter Start) nur über den erreichten Zustand
test/dnsJava.test.ts, test/scenarios/dns-lan.scenario.json, test/scenarios/dns-java-*.java.json	—	neu: fünf DNS-Abfragen gegen Java-Filius (DnsRun): Frames, Ergebnis und Dauer; seit F2.4b-1 alle wie Java; seit F2.4c dazu fünf mit rekursivem Server (dns-recursive.scenario.json, dns-recursive-java-*.java.json), einer nur bis zur Anfrage des Clients verglichen (JAVA_UNTIL: Javas Server fragt sich selbst ohne Ende)
test/tcpJava.test.ts, test/scenarios/tcp-java-*.java.json	—	neu: sechs TCP-Abläufe gegen Java-Filius (TcpRun, drei davon mit genau einem verlorenen Frame, loseFirst): Frames mit Flags und Nummern, Socket-Zustände; benannte Java-Fehler (JAVA_BUGS: nur ein SYN, der Zustand bleibt nach dem Schließen stehen), lostSynAck nur bis zum zweiten SYN verglichen (JAVA_UNTIL)
test/routeTable.test.ts	TopologyJavaRouteTableTests.swift (8 von 12 Tests)	übertragen; Geometrie- und Reducer-Tests folgen mit Editor und Dokument

packages/fls

Datei	Quelle	Art der Übertragung
src/zip.ts	Persistence/TopologyFLSArchive.swift (Fehler, Grenzen, Pfadregeln, ZIP-Leser/-Schreiber, CRC-32)	übertragen; DEFLATE über fflate, mit Apples Abschneide-Verhalten nachgebildet; Pfadfaltung (NFC, Breite, volles Case-Folding) an 41 Paaren gegen das Swift-Orakel gemessen
src/archive.ts	ebenda, Archiv-Teil von Import und Export	übertragen, ohne die XML-Ebene
src/javabeans.ts, src/javaDefaults.json	—	neu: XMLEncoder-Leser nach den Regeln von java.beans.XMLDecoder (Swift liest elementweise und verliert geteilte Werte); Getter-Standardwerte und statische Konstanten mit tools/java-oracle gemessen; merkt sich den Java-Typ jedes Primitivs an Settern, Konstruktor- und Aufrufargumenten und welche Eigenschaften ein eigener Getter angelegt hat (für beanCapture.ts)
src/importProject.ts	Persistence/TopologyProjectStore.swift (Knoten, Ports, Kabel, IP-Konfiguration, Switch/WLAN, Routen, RIP, Firewall, DHCP, Portweiterleitung, Modem, Dateisysteme, Programme, Doku-Elemente des Imports)	übertragen, Eingabe ist Javas Sicht: Name und Port-Anzahl wie Java, abgelehnte Adresse → Swift-Standard, Router-Standardgateway wie Java (Swift verliert es), jede Router-Firewall eingetragen, Konfigurationstexte wie in Swift getrimmt (swiftTrim), Rechner ohne Dateisystem leer wie in Java (Swift: Demo-Dateien), alle Programme bleiben (Swift verwirft sechs), Webserver-Dateien bleiben in /webserver (Swift: /www), keine versteckten Zustandsdateien im Dateisystem, DNS-Einträge so, wie Javas Server sie aus /dns/hosts beantwortet, WLAN eines Rechners eingeschaltet nach Javas Funk-Merkmal der Karte (auch ohne SSID; Swift: jede SSID); der Webserver behält Javas Schalter für virtuelle Hosts (Swift: aus); gegen Swifts importiertes Modell auf 13 Dateien geprüft; seit der Abnahme F2 die IP-Weiterleitung eines Knotens, wo sie vom Standard seiner Art abweicht (ipForwardingByNodeId; Java ipForwardingEnabled, übersehen bis das Firewall-Beispiel lief)
test/importProject.test.ts	—	neu: Swifts importiertes Modell (13 Dateien, begründete Abweichungen; im Dateisystem ausgenommen nur Swifts versteckte Zustandsdateien), Vollständigkeit aller 23, Pings im Kern (über einen Router; über drei Router mit manuellen Routen und Router-Gateways; seit F2.7 über Funkkabel); seit der Abnahme F2 IP-Weiterleitung und eingeschaltete DNS-Server im Schnappschuss; seit F3.2c eine Firewall, über konfig im Lauf geändert, gespeichert und wieder geöffnet (internetwork_komplett.fls); seit F3.3a eine Mail, im Lauf per SMTP angenommen, gespeichert und wieder geöffnet (email_komplett.fls); seit F3.3b eine Mail vom Programm über den MX an die andere Domain, abgeholt, gespeichert und wieder geöffnet; seit F3.4a Ordner und Datei aus der Befehlszeile, gespeichert und wieder geöffnet
src/systemSoftware.ts	Java SwitchFirmware, Betriebssystem, VermittlungsrechnerBetriebssystem, GatewayFirmware, Weiterleitungstabelle, Firewall, FirewallRule, DHCPServer, ModemFirmware, Dateisystem, Datei	neu nach Java: SSID, Lernzeit, RIP, manuelle Routen, Router-Firewall (an allen Stellen, an denen die Datei sie erreicht), DHCP (ein kaputter statischer Eintrag fällt allein weg, Java verliert alle folgenden), statische NAT, Modem, Dateisystem (bei Router und Heimrouter das, was die Datei zu den Vorlagen des Konstruktors hinzufügt, oder eine eigene Wurzel, die sie ersetzt), installierte Programme von Rechner und Notebook (eigene Anwendungen eines Projekts als erfasste Bean, beanCapture.ts); Character.isWhitespace am JDK gemessen; gegen Java geprüft; seit der Abnahme F2 ipForwardingEnabled jedes Knotens mit IP-Stapel, mit Javas Standard der Klasse (Router und Heimrouter an)
src/javaIp.ts	Java IP.inetAton/ipCheck	neu nach Java; an 46 Fällen mit Java gemessen; seit F2.5a in packages/core/src/util/javaIp.ts (der Kern liest damit RIP-Nachrichten)
src/dnsHosts.ts	Java DNSServer.leseRecordListe, ResourceRecord, Dateisystem.holeDatei; Swift State/TopologyDNSResolver.swift (TopologyDNSHostsFileCodec) als Vergleich	neu nach Java: Felder nur an einzelnen Leerzeichen, keine Kommentare, ungültige TTL → 3600, Doppelte bleiben; ins Modell kommt nur, was Java beantwortet (Typ A/MX/NS, Name nicht leer); Javas Fehler nicht übernommen: Label mit Ziffer vorn erlaubt, kein Backslash, letztes Label nicht rein numerisch (RFC 1123/3696), Typ in jeder Schreibung (RFC 4343), negative TTL ungültig (RFC 2181); an 76 Fällen mit Java und Swift gemessen
src/topology.ts	Java SzenarioVerwaltung.netzwerkLaden, Konstruktoren und Setter der Geräte; Swift Persistence/TopologyProjectStore.swift (Parser) als Vergleich	neu nach Java statt Übertragung: Geräteart aus der Klasse statt aus der Beschriftung, Geräte ohne Koordinaten bei 0,0 statt verworfen, Werte durch Javas Setter, die Zeichen-Enden eines Kabels, die Funk-Eigenschaft einer Netzwerkkarte (wireless, bis 30.09.2026 übersehen)
test/javabeans.test.ts	—	neu: je XMLDecoder-Regel ein Test; alle 23 Korpus-Dateien, Klasse und Position jedes Geräts wie Java
test/topology.test.ts	—	neu: alle 23 Korpus-Dateien Feld für Feld wie Java (Geräte, Schnittstellen, Kabel, Doku-Elemente), dazu die Regeln, die der Korpus nicht berührt; Java lädt seit M8 über den vollständigen Ladeweg, eigene Anwendungen (test/ownApplications.ts) sind bis B2 ausgenommen
test/javaIp.test.ts, test/ip-check.*	—	neu: IP.ipCheck-Fälle, Ergebnis aus Java
src/javaEmail.ts	Java EmailServer (Konten-Bean, kontenLaden/stringZuListeBenutzerkonten), EmailAnwendung (Ordner, Adressbuch, laden), EmailKonto, Email, AddressEntry, EmailUtils	neu nach Java: E-Mail-Beans über ihre Setter, /mailserver/konten.txt und /konten.txt im Format von Javas Lesern, ohne ihre Fehler (leere Felder zählen, eine kurze Zeile fällt allein weg, Nachrichten mit leerem Text oder Betreff bleiben, ; im Betreff bleibt, CRLF, beim Client die letzte vollständige Zeile); Empfänger älterer Dateien als Zeichenketten; gegen Java auf dem Korpus und an 43 Fällen geprüft (13 benannte Java-Fehler)
src/beanCapture.ts	—	neu: eine decodierte Bean zurück in die Form des Schreibers, mit Javas Zahlentypen; der Verweis auf das Betriebssystem des Knotens als Marke; was das Format nicht sagen kann (Unaufgelöstes, Field, Fabrikmethode, ein anderswo per Getter erreichtes Objekt), wird abgelehnt, nicht geraten; Rundlauf-Tests in test/beanCapture.test.ts
src/javaBeansWriter.ts	—	neu: Schreiber für das XMLDecoder-Format, Gegenstück zu javabeans.ts; ausdrücklich typisierte Eingabe, geteilte Objekte über id/idref, was XML nicht fassen kann (und CR) als <char code>; von Java selbst geprüft (BeansDump)
test/javaBeansWriter.test.ts, test/beans/	—	neu: 11 Dateien des Schreibers, von Javas XMLDecoder gelesen und beschrieben; Erwartungen von Hand
src/projectSnapshot.ts	Swift TopologyNetworkRuntimeTopologySnapshot(editorState:)	neu (Abnahme F2): das importierte Projekt als Schnappschuss des Kerns; nur die Kabel verbinden (Swifts Verbindung über die SSID nicht übernommen), nur eingeschaltete DNS-Server laufen; seit F3.1 jeder installierte Echo-Server (ein oder aus, er lässt sich zur Laufzeit schalten) und einfache Client; seit F3.2a jeder Webserver und Browser und die Dateisysteme; seit F3.2c der Rückweg projectWithSimulationChanges: die Firewalls aus dem Schnappschuss des Laufs ins Projekt, wie Java sie beim Speichern hat; seit F3.3a die installierten E-Mail-Server (ein oder aus) und auf dem Rückweg ihre Postfächer; seit F3.3b die installierten E-Mail-Programme und auf dem Rückweg ihre Ordner; seit F3.4a die Knoten mit der Befehlszeile (ihre Dateien sind die des Projekts)
test/examplesJava.test.ts, test/examples/*.java.json	—	neu (Abnahme F2): fünf Beispiele von Filius (internetwork_komplett, einfaches_rechnernetz_komplett, dns_server, nat_with_mapped_port, Internet_Komplett_…_DE) mit dem eigenen Leser eingelesen und im Kern gespielt, gegen Java-Filius (ExampleRun): je Karte Frames, Zeiten und Tabellenzeilen, die Aufrufe, die Adressen am Ende; gleichzeitig startende DHCP-Clients je Client; zwei benannte Java-Fehler (JAVA_BUGS: Ping ohne Gateway wirft eine NullPointerException; NAT-Eintrag nur für die erste Gegenstelle)
test/classicsJava.test.ts, test/exampleRun.ts, test/examples/{web,email,gnutella}.java.json	—	neu (Abnahme F3): die Unterrichtsklassiker auf Beispielen von Filius gegen Java-Filius (ExampleRun): Webseite über ihren DNS-Namen (internetwork_komplett), E-Mail zwischen zwei Netzen durch NAT und Weitergabe von Server zu Server (Internet_Komplett_…_DE), Datei per Gnutella über einen Router finden und holen, Ping, Pong und Query weitergereicht (zwei_rechnernetze_komplett, Programme vom Test eingesetzt); je Karte Frames, Zeiten und Tabellenzeilen (ohne RIP), die Zeilen jedes Programms, Mails, Teilnehmer, Ergebnisse und Dateien am Ende; Javas Fehler aus F3.6b und closedPort benannt (JAVA_BUGS); gleich lange RIP-Wege nach Javas Wahl (equalRipTies). exampleRun.ts: was beide Beispiel-Tests teilen (Datei öffnen, Javas Namen, Karten nach MAC)
src/topologyWriter.ts	Java SzenarioVerwaltung.netzwerkSpeichern, Konstruktoren von NetzwerkInterface, Port, GUIKabelItem und der Systemsoftware	neu nach Java: konfiguration.xml aus Javas Sicht — Geräte, Schnittstellen (vom Konstruktor angelegte über Getter, weitere per add), Ports über Getter-Verweise, Kabel samt Zeichen-Enden (kabelpanel), Doku-Elemente; Systemsoftware über ihre Setter: SSID, Lernzeit, RIP, manuelle Routen, DHCP-Client und -Server, statische NAT, Modem, Router-Firewall (über das konfig-Plug-in des Webservers, wie XMLEncoder sie erreicht); eigene Anwendungen eines Projekts, wie die Datei sie hatte; Dateisysteme (an die Wurzel des Konstruktors angehängt wie bei XMLEncoder, beim Router hinter dessen Vorlagen); installierte Programme nach den Dateien (Webserver, Tauschbörse und E-Mail-Server legen ihre Ordner nur an, wo sie fehlen; der DNS-Server liest /dns/hosts beim Installieren), je unter ihrem Schlüssel mit der Systemsoftware wie installApp, samt Einstellungen und persönlicher Firewall; E-Mail: Domain und Bean-Konten des Servers samt Postfächern, Ordner und Adressbuch des Clients (sein Konto steht in /konten.txt, einer Datei); Javas Fehler nicht übernommen: ein Empfänger, den eine ältere Datei als Zeichenkette hält, wird als der AddressEntry geschrieben, den Javas AddressEntry(String) daraus macht (Java legt die Zeichenkette ungeprüft in die typisierte Liste, sein E-Mail-Fenster scheitert daran), ein null-Empfänger fällt weg; Kopf „Filius version: 2.14.0 (mdg-filius)“; seit der Abnahme F2 ipForwardingEnabled, wo es vom Standard der Klasse abweicht
test/topologyWriter.test.ts, test/written.java.json	—	neu: alle 23 Korpus-Dateien gelesen und neu geschrieben, von Java geladen — Topologie, Systemsoftware, Dateisysteme und Programme samt E-Mail wie beim Original (bis auf die benannte Abweichung bei Empfängern als Zeichenkette, nur in man-in-the-middle.fls) (Java gegen Java); dazu eine künstliche Topologie mit dem, was der Korpus nicht hat (u. a. eingeschaltete Router-Firewall mit Regeln jedes Protokolls, alle Firewall-Schalter abseits der Vorgabe, Modem mit eigenem Port und Ziel, verschachtelter Dateibaum mit umbenannter Wurzel, namenlosem Ordner, Datei ohne Typ und Inhalt mit CR/CRLF und Zeichen jenseits der BMP, Heimrouter mit eigener Wurzel, jedes Filius-Programm mit Einstellungen abseits der Vorgabe samt persönlicher Firewall, von Java angelegte Ordner /peer2peer und /mailserver, E-Mail-Server und -Client mit Konto, Postfach, drei Ordnern, Adressbuch und Empfängern aller Formen)
src/exportProject.ts	Gegenstück zu importProject.ts; saveProjectArchive schreibt eine ganze .fls samt der übrigen Archiveinträge (Gegenstück: openProjectArchive in importProject.ts, das sie in archiveEntries des Modells legt); Java JHostKonfiguration.updateWifiConnection, InternetKnotenBetriebssystem.getStandardGateway/setStandardGateway	neu: Editor-Modell → Javas Sicht für den Schreiber, Schritt X1 Topologie — Geräte, Schnittstellen (MAC wie in der Simulation: aus der Datei oder aus der Port-ID abgeleitet), Kabel samt Funk (Karte drahtlos und Switch, wie Java verbindet), Gateway und DNS an allen Schnittstellen wie Javas eigene Setter, Doku-Elemente; X2 Systemsoftware — SSIDs, Lernzeit, Routen, RIP, DHCP-Client und -Server, Portweiterleitung, Firewall (Namen des Kerns als Javas Zahlen), Modems aus den Paaren des Modells (Port aus dem Paarnamen, der erste eines Paars dient, Ziel localhost); X3 Dateien von Rechner und Notebook — Typ aus der Inhaltsart (Text nach Endung, sonst text; Bild und Binärdaten nach Medientyp), Bilder und Binärdaten in Base64 wie Filius' Base64.encodeBytes (Umbruch nach 76 Zeichen, an 19 Längen mit Java gemessen); X4a Programme — je Programm die Filius-Klasse unter ihrem Namen als Schlüssel, eingeschaltete Server, Ports, virtuelle Hosts, DNS-Rekursion, Ziel des Clients (leer als null wie Javas Konstruktor), Teilnehmerzahl, persönliche Firewall; X4b E-Mail — Beans des Servers (Domain, Konten, Postfächer) und des Clients (drei Ordner, Adressbuch), /konten.txt und /mailserver/konten.txt aus den Konten des Modells neu geschrieben im Format von Filius 2.14 (EmailKonto.toString, listeBenutzerkontenZuString), ohne Javas Fehler (leere Felder statt "null"); ein Zeichen, das ein Feld im Format nicht tragen kann, wird dort zum Leerzeichen, mit Warnung; seit der Abnahme F2 die IP-Weiterleitung aus dem Modell
test/exportProject.test.ts, test/exported.java.json	—	neu: alle 23 Korpus-Dateien importiert, exportiert, geschrieben und von Java geladen — Topologie wie beim Original bis auf benannte Abweichungen (abgeleiteter MAC und abgeleitete Switch-SSID statt gewürfelter, Modem-Rollen nach Reihenfolge im Paar, Doku in Zeichenreihenfolge mit Text, Schrift und Mindestgröße des Modells, Dateien in der Ordnung und mit dem Typ des Modells, keine eigenen Dateien von Routern, Empfänger als Zeichenkette gelesen, Nachrichten des Gesendet-Ordners versendet, Konto-Dateien neu geschrieben wie Filius 2.14); die übrigen Archiveinträge (eigene Anwendungen unter projekt/anwendungen) kommen byte-gleich zurück; eigene Anwendungen auf Rechnern gehen als erfasste Bean durch das Modell (ownApplicationsByNodeId) und werden zurückgeschrieben; dazu ein künstliches Modell, das Java ebenfalls lädt
src/importEmail.ts	Persistence/TopologyProjectStore.swift (registerJavaEmailConfigurations, assignedJavaEmailMessages)	übertragen, Eingabe ist Javas Sicht: Server-Konten aus /mailserver/konten.txt, ohne Datei aus der Bean-Liste (Java verlöre sie); Client-Konto aus /konten.txt, ohne Datei aus der älteren kontoListe (Filius 2.14 liest sie nicht mehr); Konten und Nachrichten bleiben, wo Swift verwirft, was seine Prüfung nicht besteht; Vor- und Nachname getrennt; Empfangszeit nur aus der Datei (Swift nummeriert); gegen Swifts Modell geprüft
test/importEmail.test.ts, test/email-*.swift.json	State/TopologyEmail.swift (decodeJavaServer, decodeJavaClient) als Vergleich	neu: dieselben 43 Kontodateien mit Swifts Leser; wie Swift bis auf benannte Fälle, in denen Swift prüft und die ganze Datei verwirft, wo Java liest
src/javaFileSystem.ts, src/javaString.ts	Java Dateisystem.holeDatei, String.trim/split/equalsIgnoreCase	neu nach Java; die Groß-/Kleinschreibung gegenüber ASCII am JDK über die ganze BMP gemessen
test/javaEmail.test.ts, test/email-*.cases.txt, test/email-*.java.json, test/javaEmailNames.ts, test/javaFileSystem.test.ts	—	neu: Kontodateien von Server und Client, Ergebnis aus Java; Dateifund
test/dnsHosts.test.ts, test/dns-hosts.*	—	neu: /dns/hosts-Fälle, wie Java bis auf 7 benannte Java-Fehler, das Modell wie Swift bis auf benannte Fälle mit Grund
test/zip.test.ts	TopologyProjectPersistenceTests.swift (Archiv-Ablehnungstests, makeMinimalZIP, makePayloadZIP)	übertragen, ergänzt um DEFLATE-Grenzfälle
test/corpus.test.ts	—	neu: 23 Korpus-Dateien, gegengeprüft mit fflate.unzipSync
test/pathFolding.test.ts, test/path-folding.*.json	—	neu: welche Pfade dieselbe Datei meinen, Ergebnis aus dem Swift-Kern

tools/swift-oracle

Baut den unveränderten Swift-Kern (Stand 3b5ded0) unter Linux, nur zwei Ausdrücke sind für den Linux-Compiler aufgeteilt (patches/). Die Quellen selbst werden beim Bau geholt und nicht eingecheckt.