WAPPIT — fildeling direkte mellem to hjemmenetværk
Projekter
← Indlæg

WAPPIT — fildeling direkte mellem to hjemmenetværk

Bygget med: C# .NET WPF TCP/IP P2P SQLite PHP MySQL API
AI-venlig side

WAPPIT var et af vores egne projekter: en Windows-klient, der lod dig dele billeder, videoer og dokumenter direkte med familie og venner — uden at filerne først skulle op i en cloud-tjeneste. Vi byggede på den fra 2016 til 2023. Den blev færdig nok til at virke, men den blev aldrig udgivet, og der har aldrig været brugere på den.

Vi skriver om den alligevel, for det interessante ved WAPPIT var aldrig produktet. Det var transporten.

Problemet: to routere der ikke vil tale sammen

Skal du sende et feriealbum til din mor, er der grundlæggende to veje. Enten uploader du det til en tredjepart, som gemmer en kopi og sætter en grænse for, hvor stort det må være — eller også får du to hjemmenetværk til at forbinde direkte til hinanden.

Den anden vej er billigere, privat og har ingen øvre grænse. Den er også markant sværere, for begge parter sidder bag en NAT-router, der som udgangspunkt afviser al indgående trafik, ingen har bedt om. Standardløsningen er at bede brugeren sætte port forwarding op i sin router. Det er en fin løsning at give en serveradministrator, og en helt urimelig ting at bede sin mor om.

Sådan slap vi igennem NAT'en

Løsningen fandt vi selv på, og den er enklere, end den lyder.

Hver klient holder fire lyttende sockets åbne, så længe programmet kører, og melder samtidig sin egen adresse- og portliste ind til en lille presence-server cirka hvert minut. Når to venner begge er online, henter hver klient den andens adresser — og så begynder de begge at ringe op til hinanden hvert 30. sekund, med op til fem forsøg ad gangen.

Pointen er, at de ringer op samtidig. Når min klients udgående forbindelsesforsøg forlader min router, laver routeren en åbning for netop den modtager. Når din klients forsøg rammer min router et øjeblik senere, ser routeren det ikke som uopfordret indgående trafik, men som svar på den forbindelse, jeg selv lige har startet. Så den lukker det igennem. Det samme sker i din ende. To udgående opkald, der krydser hinanden, bliver til én forbindelse.

Teknikken har siden fået et navn — TCP hole punching, beskrevet i RFC 5128 — men vi kom frem til den ved at stirre på problemet, ikke ved at slå den op. Resultatet var det, vi var ude efter: brugeren skulle aldrig røre sin router.

Presence-serveren formidler kun adresser. Den ser aldrig en fil. Når de to klienter først har fat i hinanden, går hver eneste byte direkte fra det ene hjemmenetværk til det andet.

Resten af stakken

Klienten forsøgte IPv6 først og faldt tilbage til IPv4. Den slog endda Teredo til automatisk ved opstart — via netsh på Windows 7 og PowerShell på nyere versioner — så en bruger på et rent IPv4-net alligevel fik en IPv6-adresse at blive fundet på.

Selve forbindelsen var TCP med serialiserede objekter: omkring 25 beskedtyper sendt frem og tilbage som binære pakker, med en krypteret variant til det, der ikke skulle ligge åbent. Klienten var WPF på .NET Framework 4.8 med et almindeligt MVVM-lag, og hele netværks- og databasedelen var async hele vejen igennem med CancellationToken, så programmet kunne lukkes midt i en overførsel uden at hænge.

Lokalt lå en SQLite-database med venner, delte mapper og fillister. Backenden var PHP og MySQL — men udelukkende til brugere, venskaber og presence. Aldrig til filer.

Hvorfor blev den aldrig udgivet?

Transporten virkede. Det gjorde produktet omkring den ikke.

Installer, updater og beskeddelen blev aldrig gjort færdige — beskedmodulet kunne hente en indbakke, men både svar og slet stod stadig som "ikke implementeret", da vi lagde projektet fra os. Og imens blev fundamentet ældre: BinaryFormatter, som hele beskedprotokollen hvilede på, er sidenhen udfaset i .NET som en sikkerhedsrisiko, fordi den kan narres til at køre kode, når den pakker data ud. Den lod sig ikke bare løfte med over i en nyere runtime.

Så WAPPIT ligger, hvor den ligger: et projekt vi lærte meget af, og som aldrig nåede ud til nogen. Vi synes stadig, NAT-gennembruddet var en pæn løsning på et rigtigt problem.

Har I et problem, der bor nede i netværkslaget?

Ikke alt kan løses med en API-nøgle og en cloud-tjeneste. Har I noget, der skal tale direkte mellem to netværk, igennem en firewall, eller et sted hvor den nemme vej ikke findes — så tag fat i os. Første snak koster ingenting.

Del
LinkedIn X Facebook E-mail
Kunne I bruge noget lignende?

Lad os løse jeres udfordring

Fortæl os om jeres projekt, så finder vi den rette løsning sammen.

Kontakt os