Verbindungsaufbau: Nahbereich, WebRTC, TLS, Routing und ICMP

Browser besitzen keine allgemeine Schnittstelle, um beliebige TCP-Listener oder Raw-ICMP-Sockets zu öffnen. Der direkte Browserpfad verwendet einen WebRTC-Datenkanal. Signalisierung hilft den Endpunkten beim Verbindungsaufbau; sie ist nicht selbst der Dateidatenweg. Bei TURN werden Daten weitergeleitet: Das ist Relay, auch wenn der Client dafür dieselbe WebRTC-Familie verwendet.

Eine direkte Route wird erst genutzt, wenn die Gegenseite nachgewiesen hat, dass sie das gemeinte pipeit-Gerät ist. Native Clients können eigene konkrete Listener anbieten. Im Onlineweg werden Kandidaten an Geräte, Fingerprints, Anfrage und Ablauf gebunden, signiert und verschlüsselt ausgetauscht. Nicht der Backendserver scannt dabei wahllos Netze. Der Client prüft die angebotenen autorisierten Endpunkte mit begrenzter Parallelität und Zeitbudgets.

Der native TCP-Pfad prüft TLS 1.3 und die exakte gebundene Gegenstellenidentität. Danach folgt eine zufällige Challenge mit Gerätesignaturen, gebunden an die betreffende Prüfung beziehungsweise den Transferkontext. Ein offener Port, erfolgreicher Ping oder abgeschlossener Socketconnect genügt nicht als verifizierter pipeit-Peer.

Nahbereich: Wi-Fi Aware, LAN und lokale Erkennung

Im selben Raum finden sich die Apps zuerst: über Wi-Fi Aware ohne Router oder über das gemeinsame WLAN oder LAN, mit Bluetooth und lokaler Netzerkennung zum Bekanntmachen. Die Erkennung liefert nur einen Kandidaten; das Gerät muss seine Identität mit demselben TLS-1.3-Handshake und denselben Gerätesignaturen nachweisen wie auf jeder anderen direkten Route, bevor eine Datei fließt.

Geroutete Netze sind kein Sonderformat

Ist eine angebotene Adresse mit passendem Listener über Router erreichbar und die Freigabe gültig, kann derselbe TLS-Dateipfad verwendet werden. NAT braucht eine tatsächlich erreichbare Abbildung oder einen anderen unterstützten Verbindungsweg. Eine private IP allein beweist weder Erreichbarkeit noch gemeinsames LAN. Firewallfreigabe, Listener und bestätigte Identität müssen zusammenpassen.

Der ICMP-Weg für abgeschottete Linux-Hosts

Der native IPv4-ICMP-Pfad baut einen zuverlässigen begrenzten Bytestrom auf ICMP Echo Request und Reply auf; darüber läuft dieselbe TLS-Identitätsprüfung. Das ist nicht einfach „Dateibytes in Ping werfen“. Rollen, Sitzungsbindung, Reihenfolge, Bestätigungen, Wiederholungen und Ressourcenbegrenzung gehören dazu. Er muss ausdrücklich auf geeigneten Linux-Endpunkten eingerichtet sein und benötigt gezielte Betriebssystemrechte. Er ist IPv4-only, läuft zwischen Hosts, die Echo-Pakete austauschen können, und tunnelt nicht durch NAT, CGNAT oder Firewalls, die ICMP blockieren.

Lokale Kopplung ohne Onlinekonto

Native Clients können sich zusätzlich mit einer separaten lokalen Identität koppeln, unabhängig von einem Konto. Dafür werden signierte Peerprofile bewusst ausgetauscht und Fingerprints unabhängig verglichen. Der Unterschied zum Onlinepfad ist die Vertrauens- und Koordinationsquelle, nicht der Verzicht auf Authentisierung oder Inhaltsprüfung.