Files
mdg-filius/CHANGES.md
T
julian.kiedaischandClaude Opus 5.5 efc7c440f6 feat(core): a cable carries one frame after the other, as in Java
Java's SimplexVerbindung sleeps a cable's delay with the port's buffer
locked: frames on one cable leave one after the other, and a frame shows
in the packet log when it leaves. The engine now queues a frame in the
output buffer until the one before has arrived (ethernetLinkDeparture).
Swift sends a cable's frames at once; the option swiftCables keeps that for
the Swift comparison, which goes on checking everything else trace by
trace.

With the queue, the Java comparisons match within 120 ms (was 200); a
state of the TCP stories within 250 ms, where the engine's calls block
one after the other.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 16:37:45 +00:00

20 KiB
Raw Blame History

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. Abweichend von Java: drei SYN statt einem, weil Javas Wiederholungsschleife nach dem ersten Zeitablauf abbricht), 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. Klasse statt Werttyp. Noch nicht übertragen (wirft NotPortedError): Gateway-NAT, DNS, RIP, Remote Link, WLAN
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 F2.3 mit den DHCP-Einstellungen von Clients und Servern
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/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
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)
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
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/tcpJava.test.ts, test/scenarios/tcp-java-*.java.json — neu: drei TCP-Abläufe gegen Java-Filius (TcpRun): Frames mit Flags und Nummern, Socket-Zustände; ein benannter Java-Fehler (JAVA_BUGS: nur ein SYN)
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
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)
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
src/javaIp.ts Java IP.inetAton/ipCheck neu nach Java; an 46 Fällen mit Java gemessen
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/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)“
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
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.