3 ms·

> 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. Bett

> 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 :)

toast0 6y ago
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.
- rmchugh 6y ago
  Definitely not an impossible situation. Could even be a regular situation given a flaky DNS provider and a sufficient volume of requests.
- iib 6y ago
  That sounds like an interesting problem. Would you want to expand on the solution?
  - lstamour 6y ago
    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 https://github.com/michal-wrzosek/p2p-chat
  - toast0 6y ago
    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).
    - tuwtuwtuwtuw 6y ago
      > 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.
      - toast0 6y ago
        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.

toast0 6y ago

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.

rmchugh 6y ago
Definitely not an impossible situation. Could even be a regular situation given a flaky DNS provider and a sufficient volume of requests.
iib 6y ago
That sounds like an interesting problem. Would you want to expand on the solution?
- lstamour 6y ago
  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 https://github.com/michal-wrzosek/p2p-chat
- toast0 6y ago
  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).
  - tuwtuwtuwtuw 6y ago
    > 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.
    - toast0 6y ago
      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.