WAPPIT was one of our own projects: a Windows client that let you share photos, videos and documents directly with family and friends — without the files going up to a cloud service first. We worked on it from 2016 to 2023. It got finished enough to work, but it was never released, and it has never had a single user.
We're writing about it anyway, because the interesting part of WAPPIT was never the product. It was the transport.
The problem: two routers that won't talk to each other
If you want to send a holiday album to your mother, there are basically two routes. Either you upload it to a third party, which keeps a copy and caps how large it may be — or you get two home networks to connect directly to each other.
The second route is cheaper, private and has no upper limit. It is also considerably harder, because both parties sit behind a NAT router that by default rejects any incoming traffic nobody asked for. The standard fix is to ask the user to set up port forwarding on their router. That's a fine thing to hand a server administrator, and a completely unreasonable thing to ask your mother to do.
How we got through the NAT
We worked the solution out ourselves, and it's simpler than it sounds.
Each client keeps four listening sockets open for as long as the program is running, and reports its own address and port list to a small presence server roughly once a minute. When two friends are both online, each client fetches the other's addresses — and then they both start dialling each other every 30 seconds, up to five attempts at a time.
The point is that they dial simultaneously. When my client's outgoing connection attempt leaves my router, the router opens a path for exactly that destination. When your client's attempt hits my router a moment later, the router doesn't see unsolicited incoming traffic — it sees a reply to the connection I just started myself. So it lets it through. The same thing happens at your end. Two outgoing calls crossing each other become one connection.
The technique has since acquired a name — TCP hole punching, described in RFC 5128 — but we arrived at it by staring at the problem, not by looking it up. The result was what we were after: the user never had to touch their router.
The presence server only brokers addresses. It never sees a file. Once the two clients have hold of each other, every single byte goes straight from one home network to the other.
The rest of the stack
The client tried IPv6 first and fell back to IPv4. It even switched Teredo on automatically at startup — via netsh on Windows 7 and PowerShell on newer versions — so a user on a pure IPv4 network still got an IPv6 address to be found on.
The connection itself was TCP carrying serialised objects: around 25 message types sent back and forth as binary packets, with an encrypted variant for anything that shouldn't travel in the open. The client was WPF on .NET Framework 4.8 with a conventional MVVM layer, and the whole networking and database layer was async throughout with CancellationToken, so the program could be closed mid-transfer without hanging.
Locally there was a SQLite database holding friends, shared folders and file lists. The backend was PHP and MySQL — but purely for users, friendships and presence. Never for files.
Why was it never released?
The transport worked. The product around it didn't.
The installer, the updater and the messaging module were never finished — messaging could fetch an inbox, but both reply and delete still read "not implemented yet" when we put the project down. And meanwhile the foundation aged: BinaryFormatter, which the entire message protocol rested on, has since been retired in .NET as a security risk, because it can be tricked into executing code while unpacking data. It couldn't simply be carried over to a newer runtime.
So WAPPIT sits where it sits: a project we learned a great deal from, that never reached anyone. We still think the NAT punch-through was a neat answer to a real problem.
Got a problem that lives down in the network layer?
Not everything can be solved with an API key and a cloud service. If you have something that needs to talk directly between two networks, through a firewall, or somewhere the easy route simply doesn't exist — get in touch. The first conversation costs nothing.
