• Brian Boorman (unregistered)

    Happy "Form 4868" Day everybody!

  • Someone who Knows (unregistered)

    That code is poor quality but the design is right on. It tries to resolve a domain that you control, and if it can't it starts dial-up networking. The tradition is to resolve to 127.0.0.2 but oh well.

  • Yikes (unregistered)

    Nothing like a double shortcut to really create a house of cards. First shortcut: using ping instead of interrogating interfaces via system calls. Second shortcut: using exact error messages instead of error codes. Also, apparently a modem that's already connected is akin to a broadband?? That also sounds like a shortcut that could mess with intuitive decision making down the line...

  • Worf (unregistered)

    It's less a "dialup or broadband" check and more a "are we connected to the internet?" check. Since dialup links are on demand, if you are not connected, you need to start the dialup connection first.

    If you happened to already be connected, then you do nothing because you already are connected so post the data.

  • Nick (unregistered)

    Argh! The insanity!

    As has already been suggested, the general idea - ping a server you control, to check for connectivity - is a reasonable one.

    However… don’t use “Some random server”, even if it is one under your control. Instead, use “The target server”.

    It’s entirely possible that Server X could be internet-facing and publicly available, whereas Server Y is behind a corporate firewall, and requires a dial-up connection (or a VPN) before it can be accessed.

  • (nodebb)

    However… don’t use “Some random server”, even if it is one under your control. Instead, use “The target server”.

    That still doesn't always work. If you've got the server hosted as a virtual service in Azure, for example, then you get no pings at all. (MS block ICMP ECHO packets in their routers, so you really aren't going to get through.) Also, ping is typically answered by the OS kernel, so a machine could be pingable, but the service be unresponsive (for many possible reasons) so you should typically use something at the application layer; you want to see that the whole stack is there and live, not just part of it.

  • WTFGuy (unregistered)

    @dkf Not exactly. At least in my opinion.

    Yes, you ultimately need to ensure that whatever API endpoint you want to actually use is full functional. But to get there, everything upstream and at lower layers in the stack needs to be working too.

    In an environment where your own end's connectivity to the internet is not assured, I think the smarter approach is to start from things close to me, then work my way out. e.g. Can I hit my own outbound gateway router? Can I hit a well known internet target such as Google? Then, finally, can I access the API I really want, and get a non-error result?

    IMO, the reason to ask those 3 (example) questions in that order would if and only if a failure at each of those levels has a different solution that I can control with my subsequent actions in my software. There's no point in asking questions where you can't do anything about the answer. But when you can react differently, you need to ask the question to know how to react.

    For much application software, the best possible code is "Try to hit the endpoint API & simply throw up your hands and fail if it's not there. There's nothing more you can do to remedy the failure." But for that sort of middle-layer software that can reconfigure networking, use alternate routing, or back in the day, relied on intermitent connections like dial-up, addressing each failure mode for which you have a different remedy to hand makes complete sense.

    For the infrastructure situation where failures are expected to be very, very rare, you might choose for performance to simply try the API endpoint connection first and only if it fails start feeling your way outbound from your own box. But for scenarios, like using dial-up, where you know a sizeable fraction of attempts at first use will fail for lack of a connection, you may well be ahead performance-wise to just work up from the basic e.g. "Can I hit Google?".

    Of course today's code is a WTF example of that design

  • Rohit Londhe (unregistered)
    Comment held for moderation.

Leave a comment on “Classic WTF: Scratch One Inevitability”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article