Hacker News Reader

Comment by dmitriid | Hacker News Reader

> As someone who writes code that should never, ever break, and gets support tickets even for one-in-a-million breakages, testing is absolutely paramount.

Better put: you should test to acceptable limits.

A nuclear reactor or medical software should be tested with any and all possible and impossible scenarios in mind.

Some forum or chat software? Not so much.

And obviously there are 50 million shades in between :)

View on HN

The trick is, one person's impossible scenario is another person's normal operating condition.

I've made chat software work when DNS is broken. Other people say that's an impossible situation.

That sounds like an interesting problem. Would you want to expand on the solution?

The solution is fairly simple in principle. You need to have fallback IPs in your clients, that they can connect to in case DNS fails.

But that also means you need to have IPs that will last for as long as your client lasts. Which means you need to have a defined lifetime for your client. And you need to have some mechanism to validate the IPs are still your servers and not been taken over by someone else (mutual authentication).

> But that also means you need to have IPs that will last for as long as your client lasts.

It sounds like implementing this scheme without a method to rotate IP addresses would be a mistake. But maybe I'm missing something.

You could store fresher IPs after succesful connection. But that doesn't help for people who install from an older (but not expired) installer, while they're on a network with bad DNS.

First thing that occurred to me was WebRTC for P2P chat using an IP address in the STUN fallback list if DNS fails? As in https://github.com/michal-wrzosek/p2p-chat

Definitely not an impossible situation. Could even be a regular situation given a flaky DNS provider and a sufficient volume of requests.

Reply on news.ycombinator.com